Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-05-01T22:45:42Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==
Previous implementation of Expertiza:

[[File:Assignment participants.jpeg | 900px]]

Our implementation of Expertiza:

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: Manage Participantss.png | 900px]]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually.

=== Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== Add Participant ===
1. Select user from the user dropdown.

[[File: UserDropdown.png | 900px]]

2. Hover over the tool tip of each role and check if the description is visible.

[[File: HoverRole.png | 900px]]

3. Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.

4. The Add button is enabled only after the user and role are selected.

5. Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.

[[File: AddButton.png | 900px]]

6. Click on the "Add" button and confirm that the newly created user is populated in the participants table.

[[File: CreationSuccess.png | 900px]]

=== Delete Participant ===
1. Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.

[[File: DeleteButton.png | 900px]]

2. Click on the "Delete Participant" icon to trigger the delete participant popup window.

3. Verify that the delete participant popup window prompts confirmation ("Are you sure?").

[[File: DeletePopup.png | 900px]]

4. Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
5. Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
6. Ensure that the deleted user is removed from the participants table upon successful deletion.

[[File: DeletionSuccess.png | 900px]]

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024

2024-04-24T02:41:15Z

Mkolish:

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

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T06:06:21Z

Mkolish: /* 3. Delete Participant */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: Manage Participantss.png | 900px]]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually.

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
1. Select user from the user dropdown.

[[File: UserDropdown.png | 900px]]

2. Hover over the tool tip of each role and check if the description is visible.

[[File: HoverRole.png | 900px]]

3. Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.

4. The Add button is enabled only after the user and role are selected.

5. Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.

[[File: AddButton.png | 900px]]

6. Click on the "Add" button and confirm that the newly created user is populated in the participants table.

[[File: CreationSuccess.png | 900px]]

=== 3. Delete Participant ===
1. Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.

[[File: DeleteButton.png | 900px]]

2. Click on the "Delete Participant" icon to trigger the delete participant popup window.

3. Verify that the delete participant popup window prompts confirmation ("Are you sure?").

[[File: DeletePopup.png | 900px]]

4. Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
5. Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
6. Ensure that the deleted user is removed from the participants table upon successful deletion.

[[File: DeletionSuccess.png | 900px]]

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T06:04:13Z

Mkolish: /* 2. Add Participant */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: Manage Participantss.png | 900px]]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually.

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
1. Select user from the user dropdown.

[[File: UserDropdown.png | 900px]]

2. Hover over the tool tip of each role and check if the description is visible.

[[File: HoverRole.png | 900px]]

3. Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.

4. The Add button is enabled only after the user and role are selected.

5. Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.

[[File: AddButton.png | 900px]]

6. Click on the "Add" button and confirm that the newly created user is populated in the participants table.

[[File: CreationSuccess.png | 900px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:HoverRole.png

2024-04-23T05:58:51Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:57:04Z

Mkolish: /* Testing Details */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: Manage Participantss.png | 900px]]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually.

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:UserDropdown.png

2024-04-23T05:56:46Z

Mkolish:

File:DeletionSuccess.png

2024-04-23T05:56:36Z

Mkolish:

File:DeletePopup.png

2024-04-23T05:56:22Z

Mkolish:

File:DeleteButton.png

2024-04-23T05:56:08Z

Mkolish:

File:CreationSuccess.png

2024-04-23T05:55:56Z

Mkolish:

File:AddButton.png

2024-04-23T05:55:44Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:45:01Z

Mkolish: /* 5. Simplified Email Preferences and Search Functionality Removal: */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: Manage Participantss.png | 900px]]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:42:41Z

Mkolish: /* 4. Assignment Role Selection: */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: Manage Participantss.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:42:20Z

Mkolish: /* Design */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participantss.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:Manage Participantss.png

2024-04-23T05:42:01Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:41:02Z

Mkolish: /* Design */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage_Participants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:40:39Z

Mkolish: /* Design */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: Manage Participants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:Manage Participants.png

2024-04-23T05:39:44Z

Mkolish: Mkolish uploaded a new version of File:Manage Participants.png

Page showing participants

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:28:44Z

Mkolish: /* 2. Add Participant */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: ManageParticipants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer. The description of each type of role must be visible when hovered over the tool tips.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:25:36Z

Mkolish: /* 2. Add Participant */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: ManageParticipants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button and confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:19:24Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: ManageParticipants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer.
# The Add button is enabled only after the user and role are selected.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button.
# Confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:18:28Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: ManageParticipants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer.
# Hover over the "Add" button located at the top left corner to ensure that the "Add Participant" is visible.
# Click on the "Add" button.
# Confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T05:05:54Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

[[File: ManageParticipants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" is visible.
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer.
# Click on the "Add Participant" icon.
# Confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T04:14:46Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

[[File: ManageParticipants.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, the URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 2. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We have re-envisioned the participant management process for greater efficiency and user-friendliness. The previous functionality allowed for editing participants, which involved complex search queries across an extensive database of users and subsequent updates to fields. Given the complexity and resource intensity of this operation, particularly with a large number of users, we have observed that it's more streamlined to handle such changes through a deletion and recreation strategy. This method proves to be more straightforward and less error-prone than the in-place editing of user roles. As such, the edit participant feature has been deprecated. Now, modifications to participant information are handled cleanly and efficiently by removing the existing participant entry and creating a new one with the desired role and permissions, ensuring a clear state with each change and a more intuitive experience for administrators.

=== 3. Participant User Dropdown: ===
Participant creation form is removed and a new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

[[File:schema.rb.png | 900px]]

=== 4. Assignment Role Selection: ===
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

[[File: ManageParticipants.png | 900px]]

=== 5. Simplified Email Preferences and Search Functionality Removal: ===
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features. The search function was underutilized and contributed to interface clutter. The interface now has a more focused user experience with an emphasis on core functionalities.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" is visible.
# Select user from the user dropdown.
# Hover over the tool tip of each role and check if the description is visible.
# Select role of the participant i.e, either participant, reader, submitter or reviewer.
# Click on the "Add Participant" icon.
# Confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:ManageParticipants.png

2024-04-23T02:53:22Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-23T02:50:05Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==
=== Design to be implemented: ===

[[File:Assignment participants.jpeg | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Assignments/Assignment.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/public/assets/icons/info.png]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==List of changes==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

4 '''Participant User Dropdown'''
A new dropdown menu has been added to the user interface. This allows administrators to select a user and assign them as a participant within the platform. The dropdown is a part of the enhanced user management system, which streamlines user role assignments.

5. '''Assignment Role Selection'''
Radio buttons have been introduced for the assignment of specific roles. This selection mechanism enables a clear distinction between roles such as 'Participant', 'Reader', 'Reviewer', 'Submitter', or 'Mentor'. The purpose of these buttons is to facilitate the straightforward assignment of roles and ensure each user's responsibilities are clearly defined.

6. '''Simplified Email Preferences'''
To avoid cluttering the user interface and to improve overall user experience, the email preferences feature has been removed. This change supports a more focused approach to user interaction, removing less frequently used options and emphasizing the platform's primary features.

7. '''Search Functionality Removal'''
The search functionality has been removed following an assessment of its necessity. The decision to remove this feature was based on user behavior analysis, which indicated that the search function was underutilized and contributed to interface clutter. The streamlined interface now promotes a more focused user experience with an emphasis on core functionalities.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

=== 3. Edit Participant ===
# Hover over the "Edit Participant" icon located at the top right corner to ensure that the "Edit Participant" option is visible.
# Click on the "Edit Participant" icon and confirm that the edit participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without editing a new participant.
# Verify that the edit participant popup window closes after successfully editing a participant.
# Confirm that the edited user is updated in the participants table.

=== 4. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T21:13:29Z

Mkolish: /* Design */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==
=== Design to be implemented: ===

[[File:Assignment participants.jpeg | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

=== 3. Edit Participant ===
# Hover over the "Edit Participant" icon located at the top right corner to ensure that the "Edit Participant" option is visible.
# Click on the "Edit Participant" icon and confirm that the edit participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without editing a new participant.
# Verify that the edit participant popup window closes after successfully editing a participant.
# Confirm that the edited user is updated in the participants table.

=== 4. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T21:11:16Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

[[File:Assignment participants.jpeg | 900px]]

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

=== 3. Edit Participant ===
# Hover over the "Edit Participant" icon located at the top right corner to ensure that the "Edit Participant" option is visible.
# Click on the "Edit Participant" icon and confirm that the edit participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without editing a new participant.
# Verify that the edit participant popup window closes after successfully editing a participant.
# Confirm that the edited user is updated in the participants table.

=== 4. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:Assignment participants.jpeg

2024-04-08T21:08:17Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T19:51:54Z

Mkolish: /* Testing Details */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

=== 3. Edit Participant ===
# Hover over the "Edit Participant" icon located at the top right corner to ensure that the "Edit Participant" option is visible.
# Click on the "Edit Participant" icon and confirm that the edit participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without editing a new participant.
# Verify that the edit participant popup window closes after successfully editing a participant.
# Confirm that the edited user is updated in the participants table.

=== 4. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T19:34:50Z

Mkolish: /* Testing Details */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID, as well as a separate role attribute.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu near the user selection, populated with user options. Additionally, we included a separate dropdown for roles, allowing users to select the appropriate role for each participant. This setup ensures that roles are accurately associated with the model structure and maintains a direct link with assignment IDs. This streamlining reduces confusion and optimizes the creation process. Users can now efficiently assign participants with their respective roles, enhancing overall system efficiency and accuracy.

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

=== 3. Edit Participant ===
# Hover over the "Edit Participant" icon located at the top right corner to ensure that the "Edit Participant" option is visible.
# Click on the "Edit Participant" icon and confirm that the edit participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without editing a new participant.
# Verify that the edit participant popup window closes after successfully editing a participant.
# Confirm that the edited user is updated in the participants table.

=== 4. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T19:07:37Z

Mkolish: /* Testing Details */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the course in which the given assignment is present.
# The popup window also contains a dropdown which has role of the participant i.e, either submitter, reviewer, participant or reader.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T18:58:41Z

Mkolish: /* List of changes */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T18:58:23Z

Mkolish: /* URL Restructuring */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T18:58:09Z

Mkolish: /* Design */

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:DesignDiagram.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for participants.rb

2024-04-08T18:44:41Z

Mkolish: Created page with "This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517. == Description == The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema..."

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form: ''' 
[[File:ParticipantCreate.jpg | 700px]]

 
''' New Form: ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T01:36:59Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form: ''' 
[[File:ParticipantCreate.jpg | 700px]]

 
''' New Form: ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here :[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T01:36:10Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form: ''' 
[[File:ParticipantCreate.jpg | 700px]]

 
''' New Form: ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here:[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T01:35:29Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form: ''' 
[[File:ParticipantCreate.jpg | 700px]]

 
''' New Form: ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here: *[https://docs.google.com/document/d/1M0FRp_LqrkQ9E03rIqGM30PpP9UyOpmBEvS0seIWBGw/edit#heading=h.sp8wl52rdnqm Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T01:26:20Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation: 
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well. 
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form: ''' 
[[File:ParticipantCreate.jpg | 700px]]

 
''' New Form: ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu: ''' 

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience. 

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend by following the instructions given here: *[https://github.com/expertiza/reimplementation-back-end Backend Setup Instructions]

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
=== 1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants: ===

Initially, our URL was set as "assignments/participants." However, we updated it to "assignments/{id}/participants" because participants are closely tied to specific assignments. We changed by examining of the participant model, which indicated that participants belong to only users and assignments. As a result, each participant needs to be associated with a unique assignment ID. This adjustment ensures a more accurate representation of participant data within the system.

[[File:participant.rb.png | 900px]]

=== 2. Participant creation form redesigned to include only essential fields and a user dropdown menu: ===

We refined the participant creation form by removing irrelevant fields like role, email, first name, and last name, aligning it with the participant model and the database schema. Instead, we introduced a user dropdown menu, populated with options retrieved from the backend. This approach ensures direct association between participants and assignment IDs, enhancing efficiency and accuracy in participant assignment

[[File:schema.rb.png | 900px]]

Two interfaces, IParticipantResponse and IParticipantRequest, facilitate communication for user selection. When a user selects a participant from the dropdown, their corresponding details are fetched from the backend. Upon form submission, the system uses the selected user's ID to associate the participant with the chosen assignment. This process simplifies participant management and improves system efficiency.

=== 3. Edit participant functionality removed, as modification now entails deletion and recreation: ===

We redesigned how participants are created to better align with how modifications are handled. Understanding that editing a participant involves essentially deleting and recreating them, we decided to remove the edit participant feature from the interface. This simplifies the user experience, making it easier for people to navigate and interact with the system seamlessly.

==Design Patterns==

1. '''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

2. '''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

3. '''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== 1. Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== 2. Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== 3. Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]
== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T00:38:59Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation:
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well.
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form ''' 
[[File:ParticipantCreate.jpg | 700px]]

''' New Form ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu. '''

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience.

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend following the instructions given.

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants:
[[File:participant.rb.png | 900px]]
2. Participant creation form redesigned to include only essential fields and a user dropdown menu:
[[File:schema.rb.png | 900px]]
3. Edit participant functionality removed, as modification now entails deletion and recreation:

==Design Patterns==

'''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

'''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

'''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown:'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition:'''
[[File:AddedParticipant.jpg | 1000px]]

=== Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T00:38:06Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation:
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well.
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form ''' 
[[File:ParticipantCreate.jpg | 700px]]

''' New Form ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu. '''

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience.

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend following the instructions given.

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
1. URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants:
[[File:participant.rb.png | 900px]]
2. Participant creation form redesigned to include only essential fields and a user dropdown menu:
[[File:schema.rb.png | 900px]]
3. Edit participant functionality removed, as modification now entails deletion and recreation:

==Design Patterns==

'''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

'''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

'''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition'''
[[File:AddedParticipant.jpg | 1000px]]

=== Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T00:34:01Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation:
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward '''/assignments/participants'''. This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to '''/assignments/{id}/participants''', where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well.
[[File:URL.png | 900px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/aab1ce22ffeb7404bf3f169d9bb2e5b16a528fe6b Form Refinement] ===

We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

''' Old Form ''' 
[[File:ParticipantCreate.jpg | 700px]]

''' New Form ''' 
[[File:Create_Participant.png | 1000px]]

''' The user dropdown fetches user names from the backend and populates the dropdown menu. '''

[[File:User_dropdown.png | 1000px]]

=== [https://github.com/mahathii/reimplementation-front-end/commit/6340611c4b95548edc023c18c77d929bf01ec144 UI Restructuring] ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience.

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend following the instructions given.

== Components ==

* '''interfaces.ts''' : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* '''App.tsx''' : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* '''participantColumns.tsx''' : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* '''ParticipantEditor.tsx''' : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* '''participantUtil.ts''' : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* '''Participant.tsx''' : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* '''ParticipantDelete.tsx''' : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
# URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants:
[[File:participant.rb.png | 900px]]
# Participant creation form redesigned to include only essential fields and a user dropdown menu:
[[File:schema.rb.png | 900px]]
# Edit participant functionality removed, as modification now entails deletion and recreation:

==Design Patterns==

'''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

'''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

'''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition'''
[[File:AddedParticipant.jpg | 1000px]]

=== Delete Participant ===
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

'''Pop Up window for deleting participant:'''
[[File:DeletePopUp.jpg | 1000px]]

'''Message for successful participant deletion:'''
[[File:Deleted Participant.jpg | 1000px]]

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

File:Participant.rb.png

2024-03-25T00:29:13Z

Mkolish:

File:Schema.rb.png

2024-03-25T00:28:57Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-25T00:06:07Z

Mkolish:

This wiki page is for the description of changes made under E2432 OSS assignment for Spring 2024, CSC/ECE 517.

== Description ==
The aim of this project was to enhance the user interface (UI) for participants in Expertiza, an online peer review application. Initially, the URL structure was modified to accommodate individual participants associated with specific assignment IDs. Furthermore, the UI underwent significant refinements to align with the underlying data schema, enhancing usability and functionality. 
This is the design diagram for the UI implementation:
[[File:Description.png | 900px]]

== Design ==

=== [https://github.com/mahathii/reimplementation-front-end/commit/d7da1b73de0bad231a2a0b8fa15da2faa848a9eb URL Restructuring] ===

Initially, our website's link to access participant information was straightforward: [http://localhost:3000/assignments/participants](http://localhost:3000/assignments/participants). This link served as a general entry point to view all participants across different assignments. However, as our project progressed, we recognized the need for a more refined system to handle participants associated with specific assignments. To meet this requirement, we revised the link structure to [http://localhost:3000/assignments/{id}/participants](http://localhost:3000/assignments/{id}/participants), where {id} represents the unique identifier for each assignment. This adjustment enables us to access participant data within a particular assignment directly. By organizing participants in this manner, we enhance the clarity and efficiency of participant management within our application. It serves same for the student tasks as well.
[[File:URL.png | 900px]]

=== Form Refinement ===
We noticed a mismatch between the fields in our form and the actual participant model. It turned out that fields like role, email, first name, and last name didn't align with the participant model structure. After examining the participant.rb file, we realized that the participant model was associated with the user model and included an assignment ID.

To address the inconsistency, we refined the form by removing unnecessary fields and focusing on essentials. We replaced them with a dropdown menu populated with user options. This menu allows users to select participants for specific tasks and ensures direct association with assignment IDs. This streamlining reduces confusion and aligns participant data seamlessly with the model structure, optimizing the creation process. Users can now efficiently assign participants, enhancing overall system efficiency and accuracy.

==== Old Form ====
[[File:ParticipantCreate.jpg | 700px]]

==== New Form ====
[[File:Create_Participant.png | 1000px]]

==== The user dropdown fetches user names from the backend and populates the dropdown menu. ====

[[File:User_dropdown.png | 1000px]]

=== UI Restructuring ===

We changed how we handle participant creation to better match how modifications are made. Since modifying a participant is essentially like deleting and creating a new one, we removed the edit participant feature from the UI. Instead, we redesigned the UI to focus on a simpler approach to managing participants. This not only makes the system less complex but also makes it easier for users to understand and use. By simplifying the interface, users can navigate and interact with the system more smoothly, resulting in a better overall experience.

[[File:UI_Restructure.png | 1000px]]

== Database ==
For the database, we cloned and set up reimplementation backend following the instructions given.

== Components ==

* interfaces.ts : This file defines TypeScript interfaces for form-related props and fields used in React components, including options for form elements and Formik field props.

* App.tsx : This file defines the main routing structure of the React application, configuring routes and their corresponding components, including authentication, user management, institution management, roles, assignments, participants, courses, and questionnaire sections.

* participantColumns.tsx : This file defines helper functions to create columns for displaying participant data in a table, including features like sorting, filtering, and actions such as editing and deleting participants.

* ParticipantEditor.tsx : This file contains a React component for editing participant information within a modal, including form inputs for name, email, role, institution, and email preferences, with validation and submission handling.

* participantUtil.ts : This file provides utility functions and data transformations for managing participant data, including loading participant information, roles, and institutions, and transforming data for API requests and responses.

* Participant.tsx : This file defines a React component for managing participants, including displaying participant data in a table, with options for editing and deleting participants.

* ParticipantDelete.tsx : This file contains a React component for deleting a participant, presenting a modal to confirm deletion and handling the deletion request via an API call.

== Files modified ==
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/components/Form/interfaces.ts src/components/Form/interfaces.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/App.tsx src/App.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantUtil.ts src/pages/Participants/participantUtil.ts]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/Participant.tsx src/pages/Participants/Participant.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/participantColumns.tsx src/pages/Participants/participantColumns.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantEditor.tsx src/pages/Participants/ParticipantEditor.tsx]
* [https://github.com/mahathii/reimplementation-front-end/blob/main/src/pages/Participants/ParticipantDelete.tsx src/pages/Participants/ParticipantDelete.tsx]

== List of changes ==
# URL structure updated to /assignments/{id}/participants and /student_tasks/{id}/participants
# Participant creation form redesigned to include only essential fields and a user dropdown menu.
# Edit participant functionality removed, as modification now entails deletion and recreation.

==Design Patterns==

'''RESTful Design:'''

RESTful Design is an architectural style that emphasizes client-server communications that are stateless, cacheable, and layered. In the context of web development, it involves structuring URLs in a meaningful and hierarchical manner to reflect the relationships between resources.

By restructuring URLs to include specific identifiers for accessing participant information within assignments, the project adopts RESTful principles, making the application more intuitive and navigable. This method enhances the scalability and maintainability of the web services.

This design choice not only improves clarity for developers and users by making URLs self-descriptive but also facilitates better data management and access patterns within the application, aligning with modern web standards.

'''Strategy Pattern:'''

The Strategy Pattern involves defining a family of algorithms, encapsulating each one, and making them interchangeable. This pattern lets the algorithm vary independently from clients that use it, promoting flexibility in the application's functionality.

The form refinement in the project, where a dropdown menu is populated with user options based on the context (like the specific assignment), exemplifies the Strategy Pattern. It allows the selection mechanism in forms to adapt dynamically, improving the user interface and experience.

Employing this pattern enables the application to handle varying requirements gracefully, allowing for a modular approach to form configuration and interaction. This adaptability is crucial for applications that require a high degree of customization and flexibility in user input processing.

'''Facade Pattern (Simplified Interface):'''

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, simplifying complex systems by providing a simple interface.

In the project, simplifying the participant management interface by removing the edit feature and focusing on streamlined participant addition and removal demonstrates the application of a simplified interface, akin to the Facade Pattern. This change reduces complexity for the end-user, making the system more accessible and user-friendly.

This approach enhances the user experience by reducing the cognitive load and making the interaction with the system more intuitive. It reflects a thoughtful consideration of user needs and system design, aiming to make complex processes as straightforward as possible for users.

== Testing Details ==
We tested the pages manually

=== Manage Participants ===
# Verify that the "Manage Participants" page displays correctly with all necessary options (delete, create) for the participants.
# Ensure that participant details are presented in a table format.

=== Add Participant ===
# Hover over the "Add Participant" icon located at the top right corner to ensure that the "Add Participant" option is visible.
# Click on the "Add Participant" icon and confirm that the create participant popup window appears.
# In the popup window, verify that the user dropdown menu contains all users from the database.
# Test the close button to ensure that the popup window closes without creating a new participant.
# Verify that the create participant popup window closes after successfully creating a new participant.
# Confirm that the newly created user is populated in the participants table.

'''User dropdown'''
[[File:AddParticipant.jpg | 1000px]]

'''Message for successful participant addition'''
[[File:AddedParticipant.jpg | 1000px]]

'''Delete Participant'''
# Hover over the "Delete Participant" icon present in each row of the participant table to ensure its visibility.
# Click on the "Delete Participant" icon to trigger the delete participant popup window.
# Verify that the delete participant popup window prompts confirmation ("Are you sure?").
# Test the cancel button to ensure that it closes the delete participant popup window without performing the deletion.
# Click on the delete button within the popup window and confirm that it deletes the participant and closes the popup window.
# Ensure that the deleted user is removed from the participants table upon successful deletion.

==== Pop Up window for deleting participant ====
[[File:DeletePopUp.jpg | 1000px]]

==== Message for successful participant deletion ====
[[File:Deleted Participant.jpg | 1000px]]

== Relevant Links ==
GitHub repository: https://github.com/mahathii/reimplementation-front-end 
Pull request: https://github.com/expertiza/reimplementation-front-end/pull/39
== Team ==
=== Mentor ===
Kalyan Karnati 
=== Student Team ===
Anish Rao Toorpu (atoorpu@ncsu.edu) 
Mahathi Kolishetty (mkolish@ncsu.edu) 
Nitya Naga Sai Atluri (natluri@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-24T23:53:48Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-24T23:52:06Z

Mkolish:

CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb

2024-03-24T23:28:05Z

Mkolish: