Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T04:41:15Z

Hzhou33: /* Control Flow to access the concerned screens */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

In the instructor view, the instructor can choose to enable teammate review visibility permissions.

[[File:Teammate instructor view.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate instructor view.jpg

2024-12-04T04:39:50Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T04:37:36Z

Hzhou33: /* Design */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T04:34:18Z

Hzhou33: /* Design */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for administrators, instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T04:03:47Z

Hzhou33: /* Control Flow to access the concerned screens */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
[[File:Teammate view uml.jpg|800px]]
=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T04:03:30Z

Hzhou33: /* Control Flow to access the concerned screens */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
[[File:Teammate view uml.jpg|800px]]
=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.
[[File:Teammate view student off.jpg|800px]]
When the student presses the button.
[[File:Teammate view student on.jpg|800px]]
When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.
[[File:Teammate view student recevied.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate view student recevied.jpg

2024-12-04T04:01:09Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T03:56:08Z

Hzhou33:

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
[[File:Teammate view uml.jpg|800px]]
=== Control Flow to access the concerned screens ===
[[File:Teammate view student off.jpg|800px]]

[[File:Teammate view student on.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate view student off.jpg

2024-12-04T03:52:54Z

Hzhou33:

File:Teammate view student on.jpg

2024-12-04T03:52:06Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T03:46:48Z

Hzhou33: /* Design */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===
[[File:Teammate view uml.jpg|800px]]

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate view uml.jpg

2024-12-04T03:46:19Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T03:42:30Z

Hzhou33: /* Specifications */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate given only.jpg

2024-12-04T03:41:05Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T03:32:03Z

Hzhou33: /* Specifications */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems
[[File:Teammate given.jpg|1000px]]
*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate given.jpg

2024-12-04T03:31:39Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T03:29:06Z

Hzhou33: /* Specifications */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems
[[File:Teammate student view.jpg|1000px]]
*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Teammate student view.jpg

2024-12-04T03:25:06Z

Hzhou33:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T03:13:03Z

Hzhou33: /* Specifications */

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

*Testing
**All the components of the UI are functioning
**Error handling
**Reliability of the UI is maintained

=== Design ===

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:29:58Z

Hzhou33: /* 5.5 API Integration */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
'''NotificationList''':
'''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
'''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
'''NotificationForm''':
'''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
'''Form Fields''': Include title, message, and course selection with validation.
'''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
'''InstitutionList''':
'''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
'''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
'''InstitutionForm''':
'''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
'''Form Fields''': Fields include institution name, address, and details, with backend validation.
'''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* Integration Tests:
'''Objective''': Verify interactions between components.
'''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* End-to-End Tests:
'''Objective''': Validate complete user flows and role-based access.
'''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:29:46Z

Hzhou33: /* 5.4 Testing Strategy */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
'''NotificationList''':
'''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
'''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
'''NotificationForm''':
'''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
'''Form Fields''': Include title, message, and course selection with validation.
'''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
'''InstitutionList''':
'''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
'''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
'''InstitutionForm''':
'''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
'''Form Fields''': Fields include institution name, address, and details, with backend validation.
'''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* Integration Tests:
'''Objective''': Verify interactions between components.
'''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* End-to-End Tests:
'''Objective''': Validate complete user flows and role-based access.
'''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:29:03Z

Hzhou33: /* 5.2 Component Development Process */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
'''NotificationList''':
'''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
'''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
'''NotificationForm''':
'''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
'''Form Fields''': Include title, message, and course selection with validation.
'''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
'''InstitutionList''':
'''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
'''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
'''InstitutionForm''':
'''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
'''Form Fields''': Fields include institution name, address, and details, with backend validation.
'''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:28:25Z

Hzhou33: /* 4.5 Testing Strategy */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:27:36Z

Hzhou33: /* 4.3 Application of Design Patterns */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* **Unit Tests**:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* **Integration Tests**:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* **End-to-End Tests**:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:26:31Z

Hzhou33: /* 4.2 Enhanced Role Management System */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* **Container-Presenter Pattern**:
* '''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
* '''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
* '''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* **Error Handling Pattern with Error Boundaries**:
* '''Purpose''': Capture and manage errors for smoother user experience and reliability.
* '''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
* '''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* **Unit Tests**:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* **Integration Tests**:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* **End-to-End Tests**:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:26:04Z

Hzhou33: /* 4.1 Component Design and Structure */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* **Role Enumeration (ROLE Enum)**: Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* **Centralized Authentication Context (AuthContext)**: Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* **Conditional Rendering**: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* **Container-Presenter Pattern**:
* '''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
* '''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
* '''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* **Error Handling Pattern with Error Boundaries**:
* '''Purpose''': Capture and manage errors for smoother user experience and reliability.
* '''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
* '''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* **Unit Tests**:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* **Integration Tests**:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* **End-to-End Tests**:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T16:25:43Z

Hzhou33: /* 2. Scope */

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* **ReviewSummaryList**: Displays a summary list of student reviews for a specific assignment.
* **ReviewDetail**: Shows detailed information for each review, accessible upon selecting a summary.
* **ErrorBoundary**: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* **Role Enumeration (ROLE Enum)**: Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* **Centralized Authentication Context (AuthContext)**: Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* **Conditional Rendering**: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* **Container-Presenter Pattern**:
* '''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
* '''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
* '''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* **Error Handling Pattern with Error Boundaries**:
* '''Purpose''': Capture and manage errors for smoother user experience and reliability.
* '''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
* '''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* **Unit Tests**:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* **Integration Tests**:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* **End-to-End Tests**:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T14:45:49Z

Hzhou33: /* Overview */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.

- Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected data structures for better integration with the backend API.

4.5 Testing Strategy
Unit Tests:

Components like ReviewDetail and ErrorBoundary will have unit tests to ensure error handling and data display work as expected.

Integration Tests:

Verify that data flows correctly between components, especially between ReviewSummaryList and ReviewDetail.

End-to-End Tests:

Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T14:45:14Z

Hzhou33: /* 2. Scope */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.

- Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected data structures for better integration with the backend API.

4.5 Testing Strategy
Unit Tests:

Components like ReviewDetail and ErrorBoundary will have unit tests to ensure error handling and data display work as expected.

Integration Tests:

Verify that data flows correctly between components, especially between ReviewSummaryList and ReviewDetail.

End-to-End Tests:

Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T14:44:15Z

Hzhou33: /* 4. Technical Specifications and Design Patterns */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Notification Management: A page for TAs and above to create, view, and manage course-specific notifications.

- Institution Management: An interface for Instructors and higher roles to manage institutions, with strict access control.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected data structures for better integration with the backend API.

4.5 Testing Strategy
Unit Tests:

Components like ReviewDetail and ErrorBoundary will have unit tests to ensure error handling and data display work as expected.

Integration Tests:

Verify that data flows correctly between components, especially between ReviewSummaryList and ReviewDetail.

End-to-End Tests:

Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T14:42:55Z

Hzhou33: /* 4. Technical Specifications and Design Patterns */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Notification Management: A page for TAs and above to create, view, and manage course-specific notifications.

- Institution Management: An interface for Instructors and higher roles to manage institutions, with strict access control.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected data structures for better integration with the backend API.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T14:40:18Z

Hzhou33: /* 1. Objective and Goals */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Notification Management: A page for TAs and above to create, view, and manage course-specific notifications.

- Institution Management: An interface for Instructors and higher roles to manage institutions, with strict access control.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
Components are structured for modularity, reusability, and independent state management.

Core Components for Notification and Institution UIs:

- Notification Components:
- `NotificationList`: Fetches and displays notifications based on user permissions.
- `NotificationForm`: Form for creating or updating notifications, with validation.
- `NotificationToggle`: Toggle control for notification status, allowing activation or deactivation.

- Institution Components:
- `InstitutionList`: Displays a list of institutions accessible to the logged-in user.
- `InstitutionForm`: Handles institution creation and editing, restricted to instructors or administrators.

4.2 Enhanced Role Management System

The role management system integrates directly with the component design to ensure that user roles control access to each component. This enhanced system leverages the following:

1. Role Enumeration (ROLE Enum)
- Define a `ROLE` enum with roles such as `SUPER_ADMIN`, `ADMIN`, `INSTRUCTOR`, `TA`, and `STUDENT` to establish consistent role references across components.

2. Centralized Authentication Context (`AuthContext`)
- Utilize `AuthContext` to manage and provide access to role information across the application. This context will store user roles, permissions, and session information. Components can use `AuthContext` to conditionally render or enable features based on the user’s role.
- Example: `AuthContext.hasPermission('manage_institution')` checks if the user has the `INSTRUCTOR` or `ADMIN` role, determining if they can access institution management features.

3. Role-Based Conditional Rendering
- Roles control component visibility: for instance, `NotificationForm` and `InstitutionForm` are only rendered for TAs or higher and Instructors or higher, respectively.
- Boolean expressions like `isAdminOrInstructor` simplify access checks and keep the role logic modular and maintainable.

4. Identity Verification in Components
- Role verification and conditional rendering ensure users only access authorized components.
- Example for `InstitutionForm`: A conditional wrapper in the component checks `AuthContext` before rendering sensitive management forms.

4.3 Application of Design Patterns
1. Container-Presenter Pattern:
- Purpose: Separate data-fetching logic from presentation to improve readability and testability.
- Application: Each page will have a “container” component responsible for data-fetching (e.g., `InstitutionPageContainer`) and managing user permissions. The container passes data to presenter components (e.g., `InstitutionList` or `NotificationList`) for display.
- Benefits: Enhances separation of concerns, making the components cleaner, modular, and easier to test.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T12:56:55Z

Hzhou33: /* 2. Scope */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==2. Scope==
- Notification Management: A page for TAs and above to create, view, and manage course-specific notifications.

- Institution Management: An interface for Instructors and higher roles to manage institutions, with strict access control.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
Components are structured for modularity, reusability, and independent state management.

Core Components for Notification and Institution UIs:

- Notification Components:
- `NotificationList`: Fetches and displays notifications based on user permissions.
- `NotificationForm`: Form for creating or updating notifications, with validation.
- `NotificationToggle`: Toggle control for notification status, allowing activation or deactivation.

- Institution Components:
- `InstitutionList`: Displays a list of institutions accessible to the logged-in user.
- `InstitutionForm`: Handles institution creation and editing, restricted to instructors or administrators.

4.2 Enhanced Role Management System

The role management system integrates directly with the component design to ensure that user roles control access to each component. This enhanced system leverages the following:

1. Role Enumeration (ROLE Enum)
- Define a `ROLE` enum with roles such as `SUPER_ADMIN`, `ADMIN`, `INSTRUCTOR`, `TA`, and `STUDENT` to establish consistent role references across components.

2. Centralized Authentication Context (`AuthContext`)
- Utilize `AuthContext` to manage and provide access to role information across the application. This context will store user roles, permissions, and session information. Components can use `AuthContext` to conditionally render or enable features based on the user’s role.
- Example: `AuthContext.hasPermission('manage_institution')` checks if the user has the `INSTRUCTOR` or `ADMIN` role, determining if they can access institution management features.

3. Role-Based Conditional Rendering
- Roles control component visibility: for instance, `NotificationForm` and `InstitutionForm` are only rendered for TAs or higher and Instructors or higher, respectively.
- Boolean expressions like `isAdminOrInstructor` simplify access checks and keep the role logic modular and maintainable.

4. Identity Verification in Components
- Role verification and conditional rendering ensure users only access authorized components.
- Example for `InstitutionForm`: A conditional wrapper in the component checks `AuthContext` before rendering sensitive management forms.

4.3 Application of Design Patterns
1. Container-Presenter Pattern:
- Purpose: Separate data-fetching logic from presentation to improve readability and testability.
- Application: Each page will have a “container” component responsible for data-fetching (e.g., `InstitutionPageContainer`) and managing user permissions. The container passes data to presenter components (e.g., `InstitutionList` or `NotificationList`) for display.
- Benefits: Enhances separation of concerns, making the components cleaner, modular, and easier to test.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T12:56:46Z

Hzhou33: /* 2. Scope */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==2. Scope==
- Notification Management: A page for TAs and above to create, view, and manage course-specific notifications.
- Institution Management: An interface for Instructors and higher roles to manage institutions, with strict access control.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
Components are structured for modularity, reusability, and independent state management.

Core Components for Notification and Institution UIs:

- Notification Components:
- `NotificationList`: Fetches and displays notifications based on user permissions.
- `NotificationForm`: Form for creating or updating notifications, with validation.
- `NotificationToggle`: Toggle control for notification status, allowing activation or deactivation.

- Institution Components:
- `InstitutionList`: Displays a list of institutions accessible to the logged-in user.
- `InstitutionForm`: Handles institution creation and editing, restricted to instructors or administrators.

4.2 Enhanced Role Management System

The role management system integrates directly with the component design to ensure that user roles control access to each component. This enhanced system leverages the following:

1. Role Enumeration (ROLE Enum)
- Define a `ROLE` enum with roles such as `SUPER_ADMIN`, `ADMIN`, `INSTRUCTOR`, `TA`, and `STUDENT` to establish consistent role references across components.

2. Centralized Authentication Context (`AuthContext`)
- Utilize `AuthContext` to manage and provide access to role information across the application. This context will store user roles, permissions, and session information. Components can use `AuthContext` to conditionally render or enable features based on the user’s role.
- Example: `AuthContext.hasPermission('manage_institution')` checks if the user has the `INSTRUCTOR` or `ADMIN` role, determining if they can access institution management features.

3. Role-Based Conditional Rendering
- Roles control component visibility: for instance, `NotificationForm` and `InstitutionForm` are only rendered for TAs or higher and Instructors or higher, respectively.
- Boolean expressions like `isAdminOrInstructor` simplify access checks and keep the role logic modular and maintainable.

4. Identity Verification in Components
- Role verification and conditional rendering ensure users only access authorized components.
- Example for `InstitutionForm`: A conditional wrapper in the component checks `AuthContext` before rendering sensitive management forms.

4.3 Application of Design Patterns
1. Container-Presenter Pattern:
- Purpose: Separate data-fetching logic from presentation to improve readability and testability.
- Application: Each page will have a “container” component responsible for data-fetching (e.g., `InstitutionPageContainer`) and managing user permissions. The container passes data to presenter components (e.g., `InstitutionList` or `NotificationList`) for display.
- Benefits: Enhances separation of concerns, making the components cleaner, modular, and easier to test.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T12:55:54Z

Hzhou33: /* 4. Technical Specifications and Design Patterns */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==2. Scope==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
Components are structured for modularity, reusability, and independent state management.

Core Components for Notification and Institution UIs:

- Notification Components:
- `NotificationList`: Fetches and displays notifications based on user permissions.
- `NotificationForm`: Form for creating or updating notifications, with validation.
- `NotificationToggle`: Toggle control for notification status, allowing activation or deactivation.

- Institution Components:
- `InstitutionList`: Displays a list of institutions accessible to the logged-in user.
- `InstitutionForm`: Handles institution creation and editing, restricted to instructors or administrators.

4.2 Enhanced Role Management System

The role management system integrates directly with the component design to ensure that user roles control access to each component. This enhanced system leverages the following:

1. Role Enumeration (ROLE Enum)
- Define a `ROLE` enum with roles such as `SUPER_ADMIN`, `ADMIN`, `INSTRUCTOR`, `TA`, and `STUDENT` to establish consistent role references across components.

2. Centralized Authentication Context (`AuthContext`)
- Utilize `AuthContext` to manage and provide access to role information across the application. This context will store user roles, permissions, and session information. Components can use `AuthContext` to conditionally render or enable features based on the user’s role.
- Example: `AuthContext.hasPermission('manage_institution')` checks if the user has the `INSTRUCTOR` or `ADMIN` role, determining if they can access institution management features.

3. Role-Based Conditional Rendering
- Roles control component visibility: for instance, `NotificationForm` and `InstitutionForm` are only rendered for TAs or higher and Instructors or higher, respectively.
- Boolean expressions like `isAdminOrInstructor` simplify access checks and keep the role logic modular and maintainable.

4. Identity Verification in Components
- Role verification and conditional rendering ensure users only access authorized components.
- Example for `InstitutionForm`: A conditional wrapper in the component checks `AuthContext` before rendering sensitive management forms.

4.3 Application of Design Patterns
1. Container-Presenter Pattern:
- Purpose: Separate data-fetching logic from presentation to improve readability and testability.
- Application: Each page will have a “container” component responsible for data-fetching (e.g., `InstitutionPageContainer`) and managing user permissions. The container passes data to presenter components (e.g., `InstitutionList` or `NotificationList`) for display.
- Benefits: Enhances separation of concerns, making the components cleaner, modular, and easier to test.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T12:54:57Z

Hzhou33: /* 3. System Architecture */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==2. Scope==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.
1. Container-Presenter Pattern:
- Purpose: Separate data-fetching logic from presentation to improve readability and testability.
- Application: Each page will have a “container” component responsible for data-fetching (e.g., `InstitutionPageContainer`) and managing user permissions. The container passes data to presenter components (e.g., `InstitutionList` or `NotificationList`) for display.
- Benefits: Enhances separation of concerns, making the components cleaner, modular, and easier to test.

2. Observer Pattern:
- Purpose: Manage and display real-time notification updates.
- Application: A global `NotificationContext` tracks active notifications, notifying subscribed components like `NotificationList` of any updates.
- Benefits: Ensures that notifications display real-time updates, increasing engagement and immediacy for users managing or viewing notifications.

3. Role-Based Access Control (RBAC) with Context API:
- Purpose: Enforce access restrictions based on user roles.
- Application: `AuthContext` centralizes user role and permission management, enabling components to query permissions and conditionally render based on the role.
- Benefits: Centralizes access control, making it easy to audit and adjust permissions if needed.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T12:53:55Z

Hzhou33: /* 4. Technical Specifications and Design Patterns */

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==2. Scope==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==3. System Architecture==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==4. Technical Specifications and Design Patterns==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.
1. Container-Presenter Pattern:
- Purpose: Separate data-fetching logic from presentation to improve readability and testability.
- Application: Each page will have a “container” component responsible for data-fetching (e.g., `InstitutionPageContainer`) and managing user permissions. The container passes data to presenter components (e.g., `InstitutionList` or `NotificationList`) for display.
- Benefits: Enhances separation of concerns, making the components cleaner, modular, and easier to test.

2. Observer Pattern:
- Purpose: Manage and display real-time notification updates.
- Application: A global `NotificationContext` tracks active notifications, notifying subscribed components like `NotificationList` of any updates.
- Benefits: Ensures that notifications display real-time updates, increasing engagement and immediacy for users managing or viewing notifications.

3. Role-Based Access Control (RBAC) with Context API:
- Purpose: Enforce access restrictions based on user roles.
- Application: `AuthContext` centralizes user role and permission management, enabling components to query permissions and conditionally render based on the role.
- Benefits: Centralizes access control, making it easy to audit and adjust permissions if needed.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics