Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-12-04T05:18:55Z

Vshetty2: /* Relevant Links */

__TOC__

==Details about the Notification Model and Controller==

The Notification model in Expertiza serves a critical role in enhancing communication and user engagement on the platform. It is essential because it automates the process of alerting users to significant events, such as receiving feedback, team changes, or assignment updates, without requiring users to actively seek out this information. By streamlining these updates, the model reduces the risk of missed information, helping users stay on top of their responsibilities, collaborate more effectively, and respond in a timely manner. This function is particularly valuable in a platform like Expertiza, where users juggle multiple assignments, peer reviews, and team interactions, and would otherwise need to manually monitor changes and updates or rely on external tools for reminders.

The Notification model also improves the overall user experience by organizing and presenting notifications in a way that makes them easy to access and track. It stores notification details (like type, content, and timestamp) and associates them with specific users, ensuring each user receives personalized, relevant updates. Users can view notifications sorted by date or filtered by read/unread status, making it easier to prioritize tasks and responses. Ultimately, the Notification model supports Expertiza’s usability by helping users stay informed and accountable, contributing to an environment that encourages active participation and smooth collaboration across assignments.

==Objective==
The objective was to create a Notification model in the backend to handle notifications for the Expertiza system.

This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course.
Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

The main objective is to create the Notification controller and model to handle sending and receiving notifications on the Expertiza platform.

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG| center]]

===Associations===

'''Notification'''

* belongs_to :user - Links the notification to its creator (TA, instructor).

* belongs_to :course - Links the notification to a course.

'''User'''

* has_many :notifications - Users (instructors, TAs) can create multiple notifications.

* has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

* has_many :notifications - Each course can have multiple notifications.

* has_many :students, through: :enrollments - Defines which students are associated with the course.

==UML Diagram==
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==
NotificationController Implementation: Following are the controller methods:

1. create:

* Description: This method is responsible for creating a new notification. It validates the incoming data to ensure that all required fields are present and correctly formatted. Only authorized users (instructors or TAs) can create notifications. Upon successful creation, the method associates the notification with the specified course and user (creator).
* API Endpoint: POST /notifications
* Parameters:
** subject (required): The title of the notification that briefly describes its purpose (limited to 255 characters).
** description (optional): Detailed content of the notification.
** expiration_date (optional): The date until which the notification remains valid. Defaults to no expiration.
** is_active (optional): A boolean flag indicating if the notification is active (default is true).
** course_id (required): The course associated with the notification.
* Authorization: Ensures that only users with roles of TA or instructor can create a notification.
* Response:
** Success: Returns the newly created notification with a 201 status.
** Error: Returns validation errors (e.g., missing fields, invalid data) with a 422 status.

2. index:

* Description: The index method retrieves a list of notifications based on specific filters, such as active status, unread status, or course association. This endpoint ensures that students only see notifications related to the courses they are enrolled in. It supports querying with multiple optional parameters for flexibility.
* API Endpoint: GET /notifications
* Parameters: Query parameters (optional):
** is_active: Filter notifications by their active status.
** is_unread: Retrieve only unread notifications for the current user.
** course_id: Fetch notifications specific to a course.
* Authorization: Students can only access notifications for courses they are enrolled in. Instructors and TAs can view all notifications they have created.
* Response:
** Success: Returns an array of filtered notifications with a 200 status.
** Error: Returns a 403 status if unauthorized.

3. show:

* Description: This method retrieves the details of a specific notification identified by its unique ID. It ensures that the current user is authorized to view the notification (e.g., enrolled in the course or the creator of the notification).
* API Endpoint: GET /notifications/:id
* Parameters:
** id: The unique identifier of the notification to be retrieved.
* Authorization: Students can view notifications for courses they are enrolled in. Instructors and TAs can view notifications they have created.
* Response:
** Success: Returns the notification details with a 200 status.
** Error: Returns a 404 status if the notification is not found or the user is unauthorized.

4. update:

* Description: This method allows the creator of a notification (TA or instructor) to update its details. It validates the incoming data and ensures that the user is authorized to make changes.
* API Endpoint: PUT /notifications/:id
* Parameters: Fields that can be updated include subject, description, expiration_date, and is_active.
* Authorization: Only the creator of the notification can update it.
* Response:
** Success: Returns the updated notification with a 200 status.
** Error: Returns a 403 status if the user does not have the required permissions.

5. destroy:

* Description: This method deletes a specific notification. Only the user who created the notification can perform this action. The method ensures that no unauthorized users can delete notifications.
* API Endpoint: DELETE /notifications/:id
* Parameters:
** id: The unique identifier of the notification to be deleted.
* Authorization: Only the creator of the notification can delete it.
* Response:
** Success: Returns a 204 status with no content upon successful deletion.
** Error: Returns a 403 status if the user is unauthorized.

6. toggle_notification_visibility:

* Description: This method toggles the is_active status of a notification. For example, a TA or instructor can deactivate a notification that is no longer relevant. The method ensures that only the creator of the notification can perform this action.
* API Endpoint: PATCH /notifications/:id/toggle
* Parameters:
** id: The unique identifier of the notification to be toggled.
* Authorization: Only the creator of the notification can toggle its visibility.
* Response:
** Success: Returns the updated notification status with a 200 status.
** Error: Returns a 403 status if unauthorized.

Model Implementation:

1. Notification model:

* Description: The Notification model represents a single notification. It includes all attributes, validations, and associations necessary for managing notifications.
* Attributes:
** subject: The title of the notification (required, max length: 255).
** description: The detailed content of the notification.
** expiration_date: The date when the notification should expire (validated to be in the future).
** is_active: Indicates whether the notification is active (default: true).
** is_unread: Marks if a notification is unread (default: true).
** course_id: Links the notification to a course.
** user_id: Links the notification to its creator.
* Associations:
** belongs_to :course
** belongs_to :user
* Validations:
** Ensures the presence of subject, course_id, and user_id.
** Validates expiration_date to ensure it is not in the past.
* Scopes:
** active: Filters notifications that are active.
** unread: Filters unread notifications for a user.

2. User Model:

* Associations:
** has_many :notifications (creator role).
** has_many :viewable_notifications, through: :courses (student role).

3. Course Model:

* Associations:
** has_many :notifications.
** has_many :students, through: :enrollments.

== New Files ==

1. Model for Notification (models/notification.rb) 

[https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/app/models/notification.rb Commit]

<code>
class Notification < ApplicationRecord
# Associations
belongs_to :course, foreign_key: :course_name, primary_key: :name
belongs_to :user
# Validations
validates :subject, presence: true, length: { maximum: 255 }
validates :description, presence: true
validates :expiration_date, presence: true
validate :expiration_date_cannot_be_in_the_past
# Scopes
scope :active, -> { where(active_flag: true) }
scope :expired, -> { where('expiration_date < ?', Date.today) }
scope :unread_by, ->(user) {
joins(:course).where(courses: { id: user.assignments.pluck(:course_id) }).where(active_flag: true)
}
# Custom Validation for Expiration Date
def expiration_date_cannot_be_in_the_past
if expiration_date.present? && expiration_date < Date.today
errors.add(:expiration_date, "cannot be in the past")
end
end
end
</code>

 2. Controller for Notification (controllers/notification_controller.rb) 

[https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/app/controllers/api/v1/notifications_controller.rb Commit]

<code>class Api::V1::NotificationsController < ApplicationController
include AuthorizationHelper
before_action :set_notification, only: %i[show update destroy]
# GET /notifications
def index
if current_user_has_instructor_privileges? || current_user_has_ta_privileges?
@notifications = Notification.where(user_id: current_user.id)
elsif current_user_has_student_privileges?
course_names = current_user.courses.pluck(:name)
@notifications = Notification.where(course_name: course_names, active_flag: true)
else
render json: { error: 'Access denied' }, status: :forbidden
return
end
render json: @notifications
end
# GET /notifications/:id
def show
if notification_accessible?(@notification)
render json: @notification
else
render json: { error: 'You do not have access to this notification.' }, status: :forbidden
end
end
# POST /notifications
def create
# Check if the current user has sufficient privileges
unless current_user_has_instructor_privileges? || current_user_has_ta_privileges?
render json: { error: 'You are not authorized to create notifications.' }, status: :forbidden
return
end
@notification = Notification.new(notification_params)
@notification.user_id = current_user.id

if @notification.save
render json: @notification, status: :created
else
render json: @notification.errors, status: :unprocessable_entity
end
end
# PATCH/PUT /notifications/:id
def update
# Check if the current user has sufficient privileges
unless current_user_has_instructor_privileges? || current_user_has_ta_privileges?
render json: { error: 'You are not authorized to update notifications.' }, status: :forbidden
return
end
if @notification.update(notification_params)
render json: @notification, status: :ok
else
render json: @notification.errors, status: :unprocessable_entity
end
end
# DELETE /notifications/:id
def destroy
# Check if the current user has sufficient privileges
unless current_user_has_instructor_privileges? || current_user_has_ta_privileges?
render json: { error: 'You are not authorized to delete notifications.' }, status: :forbidden
return
end
if @notification.destroy
render json: { message: 'Notification deleted successfully.' }, status: :ok
else
render json: { error: 'Failed to delete the notification.' }, status: :unprocessable_entity
end
end
# PATCH /notifications/:id/toggle_active
def toggle_notification_visibility
if notification_accessible?(@notification)
@notification.update(active_flag: !@notification.active_flag)
render json: { message: 'Notification visibility toggled successfully.', notification: @notification }, status: :ok
else
render json: { error: 'You are not authorized to toggle this notification.' }, status: :forbidden
end
end
private
# Use callbacks to share common setup or constraints between actions.
def set_notification
@notification = Notification.find(params[:id])
rescue ActiveRecord::RecordNotFound
render json: { error: 'Notification not found.' }, status: :not_found
end
# Define strong parameters for notification creation/update
def notification_params
params.require(:notification).permit(:course_name, :subject, :description, :expiration_date, :active_flag)
end
# Helper method to check if a notification is accessible to the current user
def notification_accessible?(notification)
# Instructors and TAs can access their own notifications
return true if notification.user_id == current_user.id
# Students can access notifications for their courses
return true if current_user_has_student_privileges? &&
current_user.courses.exists?(name: notification.course_name)
false
end
end
</code>

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification. The create method in the NotificationController implementation aligns with this endpoint, allowing authorized users to create notifications for specific courses.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread). The index method aligns with this endpoint, allowing filtered retrieval of notifications.

3. GET /notifications/:id - View details of a specific notification. The show method aligns with this endpoint, retrieving specific notification details.

4. PUT /notifications/:id - Update a specific notification. The update method allows modification of existing notifications, respecting role-based access.

5. DELETE /notifications/:id - Delete a specific notification. The destroy method aligns with this endpoint, enabling notification deletion by authorized users.

6. PATCH /notifications/:id/toggle - Toggle active state of a notification. The toggle_notification_visibility method handles this functionality, toggling the is_active flag.

=Design Patterns and SOLID principles uses=

1. Strategy Pattern

* Use Case:
** Dynamically applying different filtering criteria for notifications (e.g., active notifications, unread notifications, notifications for a specific course).
** This modularizes the filtering logic, making it easier to extend or change in the future.
* Explanation:
** The Strategy Pattern separates filtering logic into individual strategy classes, making it easy to add new filters without modifying existing code.
** It also enhances the maintainability and testability of the system.

2. Decorator Pattern

* Use Case:
** Dynamically modifying the presentation of notifications based on user roles or other conditions.
** For example, students might see a simplified view of notifications, while instructors see a detailed view.
* Explanation:
** The Decorator Pattern adds additional functionality (like role-based formatting) without modifying the original Notification model.
** It keeps the model clean and focused on core functionality.

Following are the some of the SOLID principles with how they will be applied to the back-end development:
* Single Responsibility : Controllers handle HTTP requests, models handle data, and service objects handle business logic (e.g., sending notifications).
* Open/Closed : Extend functionality (e.g., new notification types or filters) by adding new classes or methods without modifying existing code.
* Interface Segregation : Create small, role-specific interfaces (e.g., policies for TAs, students, instructors) and separate service objects for different types of notifications.

=Testing=

This section outlines the comprehensive testing approach for the Notifications feature to ensure it meets functional and non-functional requirements. The strategy includes detailed test cases for models, controllers, role-based access, and error handling, leveraging RSpec for testing and RSwag for API documentation.

'''1. Unit Testing'''

Goal: Ensure that the Notification model functions as expected by validating its attributes, associations, and methods.

[https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/spec/models/notification_spec.rb File as on GitHub]

Key Test Cases:
* Validations:
** Presence validation for subject, description, expiration_date, course_id, and user_id.
** Length constraints on subject and description.
** Format validation for expiration_date.

* Associations:
** belongs_to :user and belongs_to :course associations are correctly established.
** Notifications have appropriate relationships with Course and User models.

* Custom Methods and Scopes:
** active_notifications: Ensure only active notifications are returned.
** unread_notifications: Validate that unread notifications are fetched correctly.

* Edge Cases:
** Notifications with an expired expiration_date should not appear in the active notifications list.
** Handling invalid foreign keys for user_id and course_id.

require 'rails_helper'
RSpec.describe Notification, type: :model do
describe 'validations' do
it { should validate_presence_of(:subject) }
it { should validate_presence_of(:description) }
it { should validate_presence_of(:expiration_date) }
it { should validate_length_of(:subject).is_at_most(100) }
end
describe 'associations' do
it { should belong_to(:user) }
it { should belong_to(:course) }
end
describe 'scopes' do
let!(:active_notification) { create(:notification, is_active: true) }
let!(:expired_notification) { create(:notification, expiration_date: Date.yesterday) }
it 'returns active notifications' do
expect(Notification.active_notifications).to include(active_notification)
expect(Notification.active_notifications).not_to include(expired_notification)
end
end
end

'''2. Controller Testing'''

Goal: Test all CRUD operations for the Notifications controller to ensure endpoints function as expected.

Key Test Cases:

* Index Action:
** Ensure all notifications for a given user are returned.
** Verify that unauthorized users cannot access the endpoint.
** Test paginated responses if applicable.
* Show Action:
** Ensure notifications can be retrieved by id.
** Handle cases where id is invalid or unauthorized.
* Create Action:
** Validate successful creation of notifications with proper attributes.
** Handle validation failures and unauthorized access.
* Update Action:
** Test updates to notification attributes.
** Ensure unauthorized users cannot perform updates.
* Delete Action:
** Verify notifications are deleted successfully.
** Test behavior when id is invalid or unauthorized.

require 'rails_helper'
RSpec.describe Api::V1::NotificationsController, type: :controller do
let(:admin) { create(:user, role: 'Admin') }
let(:student) { create(:user, role: 'Student') }
let(:notification) { create(:notification) }
describe 'GET #index' do
before { sign_in admin }
it 'returns notifications for the current user' do
get :index
expect(response).to have_http_status(:ok)
expect(json_response).to include(notification)
end
it 'denies access to unauthorized users' do
sign_out admin
sign_in student
get :index
expect(response).to have_http_status(:forbidden)
end
end
describe 'POST #create' do
context 'with valid attributes' do
it 'creates a new notification' do
expect {
post :create, params: { notification: attributes_for(:notification) }
}.to change(Notification, :count).by(1)
end
end
context 'with invalid attributes' do
it 'returns validation errors' do
post :create, params: { notification: { subject: '' } }
expect(response).to have_http_status(:unprocessable_entity)
end
end
end
end

'''3. Integration Testing'''

Goal: Ensure seamless interaction between models, controllers, and role-based access.

Key Test Cases:

* Role-Based Access:
** Verify only authorized roles (e.g., Admin, Instructor) can manage notifications.
** Ensure students can only view notifications for their enrolled courses.
* Full CRUD Workflow:
** Test end-to-end creation, updating, and deletion of notifications.
* Error Scenarios:
** Handle cases where a notification is created for a non-existent course or user.
** Verify appropriate error messages for unauthorized actions.

RSpec.describe 'Notifications Integration', type: :request do
let(:admin) { create(:user, role: 'Admin') }
let(:student) { create(:user, role: 'Student') }
let!(:notification) { create(:notification, user: admin) }
it 'allows admins to create notifications' do
sign_in admin
post '/api/v1/notifications', params: { notification: attributes_for(:notification) }
expect(response).to have_http_status(:created)
end
it 'prevents students from creating notifications' do
sign_in student
post '/api/v1/notifications', params: { notification: attributes_for(:notification) }
expect(response).to have_http_status(:forbidden)
end
end

'''4. API Documentation and Testing with RSwag'''

Goal: Generate API documentation and test all endpoints.

RSpec.describe 'Notifications API', type: :request do
path '/api/v1/notifications' do
get 'Retrieve notifications' do
tags 'Notifications'
produces 'application/json'
response '200', 'success' do
schema type: :array, items: { type: :object, properties: { id: { type: :integer }, subject: { type: :string } } }
run_test!
end
end
post 'Create a notification' do
tags 'Notifications'
consumes 'application/json'
parameter name: :notification, in: :body, schema: {
type: :object,
properties: {
subject: { type: :string },
description: { type: :string },
expiration_date: { type: :string, format: 'date' },
is_active: { type: :boolean }
},
required: %w[subject description expiration_date]
}
response '201', 'created' do
let(:notification) { { subject: 'Test', description: 'Test notification', expiration_date: '2024-12-31', is_active: true } }
run_test!
end
end
end
end

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

=Relevant Links=
* '''Github Repository:''' [https://github.com/SoubarnicaSuresh/reimplementation-back-end reimplementation back-end]
* '''Demo Video Link''' [https://youtu.be/pct11aDPMRM?si=5HdZK3EGeW1z21Y_]
* '''Pull Request Link''' [https://github.com/expertiza/reimplementation-back-end/pull/142]

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-12-04T05:14:34Z

Vshetty2: /* Relevant Links */

__TOC__

==Details about the Notification Model and Controller==

The Notification model in Expertiza serves a critical role in enhancing communication and user engagement on the platform. It is essential because it automates the process of alerting users to significant events, such as receiving feedback, team changes, or assignment updates, without requiring users to actively seek out this information. By streamlining these updates, the model reduces the risk of missed information, helping users stay on top of their responsibilities, collaborate more effectively, and respond in a timely manner. This function is particularly valuable in a platform like Expertiza, where users juggle multiple assignments, peer reviews, and team interactions, and would otherwise need to manually monitor changes and updates or rely on external tools for reminders.

The Notification model also improves the overall user experience by organizing and presenting notifications in a way that makes them easy to access and track. It stores notification details (like type, content, and timestamp) and associates them with specific users, ensuring each user receives personalized, relevant updates. Users can view notifications sorted by date or filtered by read/unread status, making it easier to prioritize tasks and responses. Ultimately, the Notification model supports Expertiza’s usability by helping users stay informed and accountable, contributing to an environment that encourages active participation and smooth collaboration across assignments.

==Objective==
The objective was to create a Notification model in the backend to handle notifications for the Expertiza system.

This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course.
Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

The main objective is to create the Notification controller and model to handle sending and receiving notifications on the Expertiza platform.

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG| center]]

===Associations===

'''Notification'''

* belongs_to :user - Links the notification to its creator (TA, instructor).

* belongs_to :course - Links the notification to a course.

'''User'''

* has_many :notifications - Users (instructors, TAs) can create multiple notifications.

* has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

* has_many :notifications - Each course can have multiple notifications.

* has_many :students, through: :enrollments - Defines which students are associated with the course.

==UML Diagram==
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==
NotificationController Implementation: Following are the controller methods:

1. create:

* Description: This method is responsible for creating a new notification. It validates the incoming data to ensure that all required fields are present and correctly formatted. Only authorized users (instructors or TAs) can create notifications. Upon successful creation, the method associates the notification with the specified course and user (creator).
* API Endpoint: POST /notifications
* Parameters:
** subject (required): The title of the notification that briefly describes its purpose (limited to 255 characters).
** description (optional): Detailed content of the notification.
** expiration_date (optional): The date until which the notification remains valid. Defaults to no expiration.
** is_active (optional): A boolean flag indicating if the notification is active (default is true).
** course_id (required): The course associated with the notification.
* Authorization: Ensures that only users with roles of TA or instructor can create a notification.
* Response:
** Success: Returns the newly created notification with a 201 status.
** Error: Returns validation errors (e.g., missing fields, invalid data) with a 422 status.

2. index:

* Description: The index method retrieves a list of notifications based on specific filters, such as active status, unread status, or course association. This endpoint ensures that students only see notifications related to the courses they are enrolled in. It supports querying with multiple optional parameters for flexibility.
* API Endpoint: GET /notifications
* Parameters: Query parameters (optional):
** is_active: Filter notifications by their active status.
** is_unread: Retrieve only unread notifications for the current user.
** course_id: Fetch notifications specific to a course.
* Authorization: Students can only access notifications for courses they are enrolled in. Instructors and TAs can view all notifications they have created.
* Response:
** Success: Returns an array of filtered notifications with a 200 status.
** Error: Returns a 403 status if unauthorized.

3. show:

* Description: This method retrieves the details of a specific notification identified by its unique ID. It ensures that the current user is authorized to view the notification (e.g., enrolled in the course or the creator of the notification).
* API Endpoint: GET /notifications/:id
* Parameters:
** id: The unique identifier of the notification to be retrieved.
* Authorization: Students can view notifications for courses they are enrolled in. Instructors and TAs can view notifications they have created.
* Response:
** Success: Returns the notification details with a 200 status.
** Error: Returns a 404 status if the notification is not found or the user is unauthorized.

4. update:

* Description: This method allows the creator of a notification (TA or instructor) to update its details. It validates the incoming data and ensures that the user is authorized to make changes.
* API Endpoint: PUT /notifications/:id
* Parameters: Fields that can be updated include subject, description, expiration_date, and is_active.
* Authorization: Only the creator of the notification can update it.
* Response:
** Success: Returns the updated notification with a 200 status.
** Error: Returns a 403 status if the user does not have the required permissions.

5. destroy:

* Description: This method deletes a specific notification. Only the user who created the notification can perform this action. The method ensures that no unauthorized users can delete notifications.
* API Endpoint: DELETE /notifications/:id
* Parameters:
** id: The unique identifier of the notification to be deleted.
* Authorization: Only the creator of the notification can delete it.
* Response:
** Success: Returns a 204 status with no content upon successful deletion.
** Error: Returns a 403 status if the user is unauthorized.

6. toggle_notification_visibility:

* Description: This method toggles the is_active status of a notification. For example, a TA or instructor can deactivate a notification that is no longer relevant. The method ensures that only the creator of the notification can perform this action.
* API Endpoint: PATCH /notifications/:id/toggle
* Parameters:
** id: The unique identifier of the notification to be toggled.
* Authorization: Only the creator of the notification can toggle its visibility.
* Response:
** Success: Returns the updated notification status with a 200 status.
** Error: Returns a 403 status if unauthorized.

Model Implementation:

1. Notification model:

* Description: The Notification model represents a single notification. It includes all attributes, validations, and associations necessary for managing notifications.
* Attributes:
** subject: The title of the notification (required, max length: 255).
** description: The detailed content of the notification.
** expiration_date: The date when the notification should expire (validated to be in the future).
** is_active: Indicates whether the notification is active (default: true).
** is_unread: Marks if a notification is unread (default: true).
** course_id: Links the notification to a course.
** user_id: Links the notification to its creator.
* Associations:
** belongs_to :course
** belongs_to :user
* Validations:
** Ensures the presence of subject, course_id, and user_id.
** Validates expiration_date to ensure it is not in the past.
* Scopes:
** active: Filters notifications that are active.
** unread: Filters unread notifications for a user.

2. User Model:

* Associations:
** has_many :notifications (creator role).
** has_many :viewable_notifications, through: :courses (student role).

3. Course Model:

* Associations:
** has_many :notifications.
** has_many :students, through: :enrollments.

== New Files ==

1. Model for Notification (models/notification.rb) 

[https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/app/models/notification.rb Commit]

<code>
class Notification < ApplicationRecord
# Associations
belongs_to :course, foreign_key: :course_name, primary_key: :name
belongs_to :user
# Validations
validates :subject, presence: true, length: { maximum: 255 }
validates :description, presence: true
validates :expiration_date, presence: true
validate :expiration_date_cannot_be_in_the_past
# Scopes
scope :active, -> { where(active_flag: true) }
scope :expired, -> { where('expiration_date < ?', Date.today) }
scope :unread_by, ->(user) {
joins(:course).where(courses: { id: user.assignments.pluck(:course_id) }).where(active_flag: true)
}
# Custom Validation for Expiration Date
def expiration_date_cannot_be_in_the_past
if expiration_date.present? && expiration_date < Date.today
errors.add(:expiration_date, "cannot be in the past")
end
end
end
</code>

 2. Controller for Notification (controllers/notification_controller.rb) 

[https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/app/controllers/api/v1/notifications_controller.rb Commit]

<code>class Api::V1::NotificationsController < ApplicationController
include AuthorizationHelper
before_action :set_notification, only: %i[show update destroy]
# GET /notifications
def index
if current_user_has_instructor_privileges? || current_user_has_ta_privileges?
@notifications = Notification.where(user_id: current_user.id)
elsif current_user_has_student_privileges?
course_names = current_user.courses.pluck(:name)
@notifications = Notification.where(course_name: course_names, active_flag: true)
else
render json: { error: 'Access denied' }, status: :forbidden
return
end
render json: @notifications
end
# GET /notifications/:id
def show
if notification_accessible?(@notification)
render json: @notification
else
render json: { error: 'You do not have access to this notification.' }, status: :forbidden
end
end
# POST /notifications
def create
# Check if the current user has sufficient privileges
unless current_user_has_instructor_privileges? || current_user_has_ta_privileges?
render json: { error: 'You are not authorized to create notifications.' }, status: :forbidden
return
end
@notification = Notification.new(notification_params)
@notification.user_id = current_user.id

if @notification.save
render json: @notification, status: :created
else
render json: @notification.errors, status: :unprocessable_entity
end
end
# PATCH/PUT /notifications/:id
def update
# Check if the current user has sufficient privileges
unless current_user_has_instructor_privileges? || current_user_has_ta_privileges?
render json: { error: 'You are not authorized to update notifications.' }, status: :forbidden
return
end
if @notification.update(notification_params)
render json: @notification, status: :ok
else
render json: @notification.errors, status: :unprocessable_entity
end
end
# DELETE /notifications/:id
def destroy
# Check if the current user has sufficient privileges
unless current_user_has_instructor_privileges? || current_user_has_ta_privileges?
render json: { error: 'You are not authorized to delete notifications.' }, status: :forbidden
return
end
if @notification.destroy
render json: { message: 'Notification deleted successfully.' }, status: :ok
else
render json: { error: 'Failed to delete the notification.' }, status: :unprocessable_entity
end
end
# PATCH /notifications/:id/toggle_active
def toggle_notification_visibility
if notification_accessible?(@notification)
@notification.update(active_flag: !@notification.active_flag)
render json: { message: 'Notification visibility toggled successfully.', notification: @notification }, status: :ok
else
render json: { error: 'You are not authorized to toggle this notification.' }, status: :forbidden
end
end
private
# Use callbacks to share common setup or constraints between actions.
def set_notification
@notification = Notification.find(params[:id])
rescue ActiveRecord::RecordNotFound
render json: { error: 'Notification not found.' }, status: :not_found
end
# Define strong parameters for notification creation/update
def notification_params
params.require(:notification).permit(:course_name, :subject, :description, :expiration_date, :active_flag)
end
# Helper method to check if a notification is accessible to the current user
def notification_accessible?(notification)
# Instructors and TAs can access their own notifications
return true if notification.user_id == current_user.id
# Students can access notifications for their courses
return true if current_user_has_student_privileges? &&
current_user.courses.exists?(name: notification.course_name)
false
end
end
</code>

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification. The create method in the NotificationController implementation aligns with this endpoint, allowing authorized users to create notifications for specific courses.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread). The index method aligns with this endpoint, allowing filtered retrieval of notifications.

3. GET /notifications/:id - View details of a specific notification. The show method aligns with this endpoint, retrieving specific notification details.

4. PUT /notifications/:id - Update a specific notification. The update method allows modification of existing notifications, respecting role-based access.

5. DELETE /notifications/:id - Delete a specific notification. The destroy method aligns with this endpoint, enabling notification deletion by authorized users.

6. PATCH /notifications/:id/toggle - Toggle active state of a notification. The toggle_notification_visibility method handles this functionality, toggling the is_active flag.

=Design Patterns and SOLID principles uses=

1. Strategy Pattern

* Use Case:
** Dynamically applying different filtering criteria for notifications (e.g., active notifications, unread notifications, notifications for a specific course).
** This modularizes the filtering logic, making it easier to extend or change in the future.
* Explanation:
** The Strategy Pattern separates filtering logic into individual strategy classes, making it easy to add new filters without modifying existing code.
** It also enhances the maintainability and testability of the system.

2. Decorator Pattern

* Use Case:
** Dynamically modifying the presentation of notifications based on user roles or other conditions.
** For example, students might see a simplified view of notifications, while instructors see a detailed view.
* Explanation:
** The Decorator Pattern adds additional functionality (like role-based formatting) without modifying the original Notification model.
** It keeps the model clean and focused on core functionality.

Following are the some of the SOLID principles with how they will be applied to the back-end development:
* Single Responsibility : Controllers handle HTTP requests, models handle data, and service objects handle business logic (e.g., sending notifications).
* Open/Closed : Extend functionality (e.g., new notification types or filters) by adding new classes or methods without modifying existing code.
* Interface Segregation : Create small, role-specific interfaces (e.g., policies for TAs, students, instructors) and separate service objects for different types of notifications.

=Testing=

This section outlines the comprehensive testing approach for the Notifications feature to ensure it meets functional and non-functional requirements. The strategy includes detailed test cases for models, controllers, role-based access, and error handling, leveraging RSpec for testing and RSwag for API documentation.

'''1. Unit Testing'''

Goal: Ensure that the Notification model functions as expected by validating its attributes, associations, and methods.

[https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/spec/models/notification_spec.rb File as on GitHub]

Key Test Cases:
* Validations:
** Presence validation for subject, description, expiration_date, course_id, and user_id.
** Length constraints on subject and description.
** Format validation for expiration_date.

* Associations:
** belongs_to :user and belongs_to :course associations are correctly established.
** Notifications have appropriate relationships with Course and User models.

* Custom Methods and Scopes:
** active_notifications: Ensure only active notifications are returned.
** unread_notifications: Validate that unread notifications are fetched correctly.

* Edge Cases:
** Notifications with an expired expiration_date should not appear in the active notifications list.
** Handling invalid foreign keys for user_id and course_id.

require 'rails_helper'
RSpec.describe Notification, type: :model do
describe 'validations' do
it { should validate_presence_of(:subject) }
it { should validate_presence_of(:description) }
it { should validate_presence_of(:expiration_date) }
it { should validate_length_of(:subject).is_at_most(100) }
end
describe 'associations' do
it { should belong_to(:user) }
it { should belong_to(:course) }
end
describe 'scopes' do
let!(:active_notification) { create(:notification, is_active: true) }
let!(:expired_notification) { create(:notification, expiration_date: Date.yesterday) }
it 'returns active notifications' do
expect(Notification.active_notifications).to include(active_notification)
expect(Notification.active_notifications).not_to include(expired_notification)
end
end
end

'''2. Controller Testing'''

Goal: Test all CRUD operations for the Notifications controller to ensure endpoints function as expected.

Key Test Cases:

* Index Action:
** Ensure all notifications for a given user are returned.
** Verify that unauthorized users cannot access the endpoint.
** Test paginated responses if applicable.
* Show Action:
** Ensure notifications can be retrieved by id.
** Handle cases where id is invalid or unauthorized.
* Create Action:
** Validate successful creation of notifications with proper attributes.
** Handle validation failures and unauthorized access.
* Update Action:
** Test updates to notification attributes.
** Ensure unauthorized users cannot perform updates.
* Delete Action:
** Verify notifications are deleted successfully.
** Test behavior when id is invalid or unauthorized.

require 'rails_helper'
RSpec.describe Api::V1::NotificationsController, type: :controller do
let(:admin) { create(:user, role: 'Admin') }
let(:student) { create(:user, role: 'Student') }
let(:notification) { create(:notification) }
describe 'GET #index' do
before { sign_in admin }
it 'returns notifications for the current user' do
get :index
expect(response).to have_http_status(:ok)
expect(json_response).to include(notification)
end
it 'denies access to unauthorized users' do
sign_out admin
sign_in student
get :index
expect(response).to have_http_status(:forbidden)
end
end
describe 'POST #create' do
context 'with valid attributes' do
it 'creates a new notification' do
expect {
post :create, params: { notification: attributes_for(:notification) }
}.to change(Notification, :count).by(1)
end
end
context 'with invalid attributes' do
it 'returns validation errors' do
post :create, params: { notification: { subject: '' } }
expect(response).to have_http_status(:unprocessable_entity)
end
end
end
end

'''3. Integration Testing'''

Goal: Ensure seamless interaction between models, controllers, and role-based access.

Key Test Cases:

* Role-Based Access:
** Verify only authorized roles (e.g., Admin, Instructor) can manage notifications.
** Ensure students can only view notifications for their enrolled courses.
* Full CRUD Workflow:
** Test end-to-end creation, updating, and deletion of notifications.
* Error Scenarios:
** Handle cases where a notification is created for a non-existent course or user.
** Verify appropriate error messages for unauthorized actions.

RSpec.describe 'Notifications Integration', type: :request do
let(:admin) { create(:user, role: 'Admin') }
let(:student) { create(:user, role: 'Student') }
let!(:notification) { create(:notification, user: admin) }
it 'allows admins to create notifications' do
sign_in admin
post '/api/v1/notifications', params: { notification: attributes_for(:notification) }
expect(response).to have_http_status(:created)
end
it 'prevents students from creating notifications' do
sign_in student
post '/api/v1/notifications', params: { notification: attributes_for(:notification) }
expect(response).to have_http_status(:forbidden)
end
end

'''4. API Documentation and Testing with RSwag'''

Goal: Generate API documentation and test all endpoints.

RSpec.describe 'Notifications API', type: :request do
path '/api/v1/notifications' do
get 'Retrieve notifications' do
tags 'Notifications'
produces 'application/json'
response '200', 'success' do
schema type: :array, items: { type: :object, properties: { id: { type: :integer }, subject: { type: :string } } }
run_test!
end
end
post 'Create a notification' do
tags 'Notifications'
consumes 'application/json'
parameter name: :notification, in: :body, schema: {
type: :object,
properties: {
subject: { type: :string },
description: { type: :string },
expiration_date: { type: :string, format: 'date' },
is_active: { type: :boolean }
},
required: %w[subject description expiration_date]
}
response '201', 'created' do
let(:notification) { { subject: 'Test', description: 'Test notification', expiration_date: '2024-12-31', is_active: true } }
run_test!
end
end
end
end

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

=Relevant Links=
* '''Github Repository:''' [https://github.com/SoubarnicaSuresh/reimplementation-back-end reimplementation back-end]
* '''Demo Video Link''' []
* '''Pull Request Link''' [https://github.com/expertiza/reimplementation-back-end/pull/142]

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-18T03:41:59Z

Vshetty2: /* Testing */

__TOC__

==Details about the Notification Model and Controller==

The Notification model in Expertiza serves a critical role in enhancing communication and user engagement on the platform. It is essential because it automates the process of alerting users to significant events, such as receiving feedback, team changes, or assignment updates, without requiring users to actively seek out this information. By streamlining these updates, the model reduces the risk of missed information, helping users stay on top of their responsibilities, collaborate more effectively, and respond in a timely manner. This function is particularly valuable in a platform like Expertiza, where users juggle multiple assignments, peer reviews, and team interactions, and would otherwise need to manually monitor changes and updates or rely on external tools for reminders.

The Notification model also improves the overall user experience by organizing and presenting notifications in a way that makes them easy to access and track. It stores notification details (like type, content, and timestamp) and associates them with specific users, ensuring each user receives personalized, relevant updates. Users can view notifications sorted by date or filtered by read/unread status, making it easier to prioritize tasks and responses. Ultimately, the Notification model supports Expertiza’s usability by helping users stay informed and accountable, contributing to an environment that encourages active participation and smooth collaboration across assignments.

==Objective==
The objective was to create a Notification model in the backend to handle notifications for the Expertiza system.

This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course.
Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

The main objective is to create the Notification controller and model to handle sending and receiving notifications on the Expertiza platform.

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG| center]]

===Associations===

'''Notification'''

* belongs_to :user - Links the notification to its creator (TA, instructor).

* belongs_to :course - Links the notification to a course.

'''User'''

* has_many :notifications - Users (instructors, TAs) can create multiple notifications.

* has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

* has_many :notifications - Each course can have multiple notifications.

* has_many :students, through: :enrollments - Defines which students are associated with the course.

==UML Diagram==
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==
NotificationController Implementation: Following are the controller methods:

1. create:

* Description: This method is responsible for creating a new notification. It validates the incoming data to ensure that all required fields are present and correctly formatted. Only authorized users (instructors or TAs) can create notifications. Upon successful creation, the method associates the notification with the specified course and user (creator).
* API Endpoint: POST /notifications
* Parameters:
** subject (required): The title of the notification that briefly describes its purpose (limited to 255 characters).
** description (optional): Detailed content of the notification.
** expiration_date (optional): The date until which the notification remains valid. Defaults to no expiration.
** is_active (optional): A boolean flag indicating if the notification is active (default is true).
** course_id (required): The course associated with the notification.
* Authorization: Ensures that only users with roles of TA or instructor can create a notification.
* Response:
** Success: Returns the newly created notification with a 201 status.
** Error: Returns validation errors (e.g., missing fields, invalid data) with a 422 status.

2. index:

* Description: The index method retrieves a list of notifications based on specific filters, such as active status, unread status, or course association. This endpoint ensures that students only see notifications related to the courses they are enrolled in. It supports querying with multiple optional parameters for flexibility.
* API Endpoint: GET /notifications
* Parameters: Query parameters (optional):
** is_active: Filter notifications by their active status.
** is_unread: Retrieve only unread notifications for the current user.
** course_id: Fetch notifications specific to a course.
* Authorization: Students can only access notifications for courses they are enrolled in. Instructors and TAs can view all notifications they have created.
* Response:
** Success: Returns an array of filtered notifications with a 200 status.
** Error: Returns a 403 status if unauthorized.

3. show:

* Description: This method retrieves the details of a specific notification identified by its unique ID. It ensures that the current user is authorized to view the notification (e.g., enrolled in the course or the creator of the notification).
* API Endpoint: GET /notifications/:id
* Parameters:
** id: The unique identifier of the notification to be retrieved.
* Authorization: Students can view notifications for courses they are enrolled in. Instructors and TAs can view notifications they have created.
* Response:
** Success: Returns the notification details with a 200 status.
** Error: Returns a 404 status if the notification is not found or the user is unauthorized.

4. update:

* Description: This method allows the creator of a notification (TA or instructor) to update its details. It validates the incoming data and ensures that the user is authorized to make changes.
* API Endpoint: PUT /notifications/:id
* Parameters: Fields that can be updated include subject, description, expiration_date, and is_active.
* Authorization: Only the creator of the notification can update it.
* Response:
** Success: Returns the updated notification with a 200 status.
** Error: Returns a 403 status if the user does not have the required permissions.

5. destroy:

* Description: This method deletes a specific notification. Only the user who created the notification can perform this action. The method ensures that no unauthorized users can delete notifications.
* API Endpoint: DELETE /notifications/:id
* Parameters:
** id: The unique identifier of the notification to be deleted.
* Authorization: Only the creator of the notification can delete it.
* Response:
** Success: Returns a 204 status with no content upon successful deletion.
** Error: Returns a 403 status if the user is unauthorized.

6. toggle_notification_visibility:

* Description: This method toggles the is_active status of a notification. For example, a TA or instructor can deactivate a notification that is no longer relevant. The method ensures that only the creator of the notification can perform this action.
* API Endpoint: PATCH /notifications/:id/toggle
* Parameters:
** id: The unique identifier of the notification to be toggled.
* Authorization: Only the creator of the notification can toggle its visibility.
* Response:
** Success: Returns the updated notification status with a 200 status.
** Error: Returns a 403 status if unauthorized.

Model Implementation:

1. Notification model:

* Description: The Notification model represents a single notification. It includes all attributes, validations, and associations necessary for managing notifications.
* Attributes:
** subject: The title of the notification (required, max length: 255).
** description: The detailed content of the notification.
** expiration_date: The date when the notification should expire (validated to be in the future).
** is_active: Indicates whether the notification is active (default: true).
** is_unread: Marks if a notification is unread (default: true).
** course_id: Links the notification to a course.
** user_id: Links the notification to its creator.
* Associations:
** belongs_to :course
** belongs_to :user
* Validations:
** Ensures the presence of subject, course_id, and user_id.
** Validates expiration_date to ensure it is not in the past.
* Scopes:
** active: Filters notifications that are active.
** unread: Filters unread notifications for a user.

2. User Model:

* Associations:
** has_many :notifications (creator role).
** has_many :viewable_notifications, through: :courses (student role).

3. Course Model:

* Associations:
** has_many :notifications.
** has_many :students, through: :enrollments.

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification. The create method in the NotificationController implementation aligns with this endpoint, allowing authorized users to create notifications for specific courses.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread). The index method aligns with this endpoint, allowing filtered retrieval of notifications.

3. GET /notifications/:id - View details of a specific notification. The show method aligns with this endpoint, retrieving specific notification details.

4. PUT /notifications/:id - Update a specific notification. The update method allows modification of existing notifications, respecting role-based access.

5. DELETE /notifications/:id - Delete a specific notification. The destroy method aligns with this endpoint, enabling notification deletion by authorized users.

6. PATCH /notifications/:id/toggle - Toggle active state of a notification. The toggle_notification_visibility method handles this functionality, toggling the is_active flag.

=Design Pattern=

1. Strategy Pattern

* Use Case:
** Dynamically applying different filtering criteria for notifications (e.g., active notifications, unread notifications, notifications for a specific course).
** This modularizes the filtering logic, making it easier to extend or change in the future.
* Explanation:
** The Strategy Pattern separates filtering logic into individual strategy classes, making it easy to add new filters without modifying existing code.
** It also enhances the maintainability and testability of the system.

2. Decorator Pattern

* Use Case:
** Dynamically modifying the presentation of notifications based on user roles or other conditions.
** For example, students might see a simplified view of notifications, while instructors see a detailed view.
* Explanation:
** The Decorator Pattern adds additional functionality (like role-based formatting) without modifying the original Notification model.
** It keeps the model clean and focused on core functionality.

3. Singleton Pattern

* Use Case:
** Managing a global notification scheduler or manager, ensuring that only one instance exists.
* Explanation:
** The Singleton Pattern ensures that there is only one centralized manager for handling notification-related tasks, such as scheduling or batch operations.

4. Chain of Responsibility Pattern

* Use Case:
** Modularizing the validation logic for notifications (e.g., checking permissions, validating expiration dates, ensuring uniqueness).
* Explanation:
** The Chain of Responsibility Pattern allows you to break down validation or processing logic into discrete steps, improving code readability and maintainability.

Following are the some of the SOLID principles with how they will be applied to the back-end development:
* Single Responsibility : Controllers handle HTTP requests, models handle data, and service objects handle business logic (e.g., sending notifications).
* Open/Closed : Extend functionality (e.g., new notification types or filters) by adding new classes or methods without modifying existing code.
* Interface Segregation : Create small, role-specific interfaces (e.g., policies for TAs, students, instructors) and separate service objects for different types of notifications.

=Testing=

This section outlines the comprehensive testing approach for the Notifications feature to ensure it meets functional and non-functional requirements. The strategy includes detailed test cases for models, controllers, role-based access, and error handling, leveraging RSpec for testing and RSwag for API documentation.

'''1. Unit Testing'''

Goal: Ensure that the Notification model functions as expected by validating its attributes, associations, and methods.

Key Test Cases:
* Validations:
** Presence validation for subject, description, expiration_date, course_id, and user_id.
** Length constraints on subject and description.
** Format validation for expiration_date.

* Associations:
** belongs_to :user and belongs_to :course associations are correctly established.
** Notifications have appropriate relationships with Course and User models.

* Custom Methods and Scopes:
** active_notifications: Ensure only active notifications are returned.
** unread_notifications: Validate that unread notifications are fetched correctly.

* Edge Cases:
** Notifications with an expired expiration_date should not appear in the active notifications list.
** Handling invalid foreign keys for user_id and course_id.

require 'rails_helper'
RSpec.describe Notification, type: :model do
describe 'validations' do
it { should validate_presence_of(:subject) }
it { should validate_presence_of(:description) }
it { should validate_presence_of(:expiration_date) }
it { should validate_length_of(:subject).is_at_most(100) }
end
describe 'associations' do
it { should belong_to(:user) }
it { should belong_to(:course) }
end
describe 'scopes' do
let!(:active_notification) { create(:notification, is_active: true) }
let!(:expired_notification) { create(:notification, expiration_date: Date.yesterday) }
it 'returns active notifications' do
expect(Notification.active_notifications).to include(active_notification)
expect(Notification.active_notifications).not_to include(expired_notification)
end
end
end

'''2. Controller Testing'''

Goal: Test all CRUD operations for the Notifications controller to ensure endpoints function as expected.

Key Test Cases:

* Index Action:
** Ensure all notifications for a given user are returned.
** Verify that unauthorized users cannot access the endpoint.
** Test paginated responses if applicable.
* Show Action:
** Ensure notifications can be retrieved by id.
** Handle cases where id is invalid or unauthorized.
* Create Action:
** Validate successful creation of notifications with proper attributes.
** Handle validation failures and unauthorized access.
* Update Action:
** Test updates to notification attributes.
** Ensure unauthorized users cannot perform updates.
* Delete Action:
** Verify notifications are deleted successfully.
** Test behavior when id is invalid or unauthorized.

require 'rails_helper'
RSpec.describe Api::V1::NotificationsController, type: :controller do
let(:admin) { create(:user, role: 'Admin') }
let(:student) { create(:user, role: 'Student') }
let(:notification) { create(:notification) }
describe 'GET #index' do
before { sign_in admin }
it 'returns notifications for the current user' do
get :index
expect(response).to have_http_status(:ok)
expect(json_response).to include(notification)
end
it 'denies access to unauthorized users' do
sign_out admin
sign_in student
get :index
expect(response).to have_http_status(:forbidden)
end
end
describe 'POST #create' do
context 'with valid attributes' do
it 'creates a new notification' do
expect {
post :create, params: { notification: attributes_for(:notification) }
}.to change(Notification, :count).by(1)
end
end
context 'with invalid attributes' do
it 'returns validation errors' do
post :create, params: { notification: { subject: '' } }
expect(response).to have_http_status(:unprocessable_entity)
end
end
end
end

'''3. Integration Testing'''

Goal: Ensure seamless interaction between models, controllers, and role-based access.

Key Test Cases:

* Role-Based Access:
** Verify only authorized roles (e.g., Admin, Instructor) can manage notifications.
** Ensure students can only view notifications for their enrolled courses.
* Full CRUD Workflow:
** Test end-to-end creation, updating, and deletion of notifications.
* Error Scenarios:
** Handle cases where a notification is created for a non-existent course or user.
** Verify appropriate error messages for unauthorized actions.

RSpec.describe 'Notifications Integration', type: :request do
let(:admin) { create(:user, role: 'Admin') }
let(:student) { create(:user, role: 'Student') }
let!(:notification) { create(:notification, user: admin) }
it 'allows admins to create notifications' do
sign_in admin
post '/api/v1/notifications', params: { notification: attributes_for(:notification) }
expect(response).to have_http_status(:created)
end
it 'prevents students from creating notifications' do
sign_in student
post '/api/v1/notifications', params: { notification: attributes_for(:notification) }
expect(response).to have_http_status(:forbidden)
end
end

'''4. API Documentation and Testing with RSwag'''

Goal: Generate API documentation and test all endpoints.

RSpec.describe 'Notifications API', type: :request do
path '/api/v1/notifications' do
get 'Retrieve notifications' do
tags 'Notifications'
produces 'application/json'
response '200', 'success' do
schema type: :array, items: { type: :object, properties: { id: { type: :integer }, subject: { type: :string } } }
run_test!
end
end
post 'Create a notification' do
tags 'Notifications'
consumes 'application/json'
parameter name: :notification, in: :body, schema: {
type: :object,
properties: {
subject: { type: :string },
description: { type: :string },
expiration_date: { type: :string, format: 'date' },
is_active: { type: :boolean }
},
required: %w[subject description expiration_date]
}
response '201', 'created' do
let(:notification) { { subject: 'Test', description: 'Test notification', expiration_date: '2024-12-31', is_active: true } }
run_test!
end
end
end
end

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

=Relevant Links=
* '''Github Repository:''' [https://github.com/SoubarnicaSuresh/reimplementation-back-end reimplementation back-end]

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:11:49Z

Vshetty2: /* Schema */

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG| center]]

===Associations===

'''Notification'''

* belongs_to :user - Links the notification to its creator (TA, instructor).

* belongs_to :course - Links the notification to a course.

'''User'''

* has_many :notifications - Users (instructors, TAs) can create multiple notifications.

* has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

* has_many :notifications - Each course can have multiple notifications.

* has_many :students, through: :enrollments - Defines which students are associated with the course.

==UML Diagram==
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:11:35Z

Vshetty2:

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG]]

===Associations===

'''Notification'''

* belongs_to :user - Links the notification to its creator (TA, instructor).

* belongs_to :course - Links the notification to a course.

'''User'''

* has_many :notifications - Users (instructors, TAs) can create multiple notifications.

* has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

* has_many :notifications - Each course can have multiple notifications.

* has_many :students, through: :enrollments - Defines which students are associated with the course.

==UML Diagram==
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:11:05Z

Vshetty2: /* Associations */

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG]]

===Associations===

'''Notification'''

* belongs_to :user - Links the notification to its creator (TA, instructor).

* belongs_to :course - Links the notification to a course.

'''User'''

* has_many :notifications - Users (instructors, TAs) can create multiple notifications.

* has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

* has_many :notifications - Each course can have multiple notifications.

* has_many :students, through: :enrollments - Defines which students are associated with the course.

===UML Diagram===
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:10:24Z

Vshetty2: /* Requirements */

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic: Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG]]

===Associations===

'''Notification'''

belongs_to :user - Links the notification to its creator (TA, instructor).

belongs_to :course - Links the notification to a course.

'''User'''

has_many :notifications - Users (instructors, TAs) can create multiple notifications.

has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

has_many :notifications - Each course can have multiple notifications.

has_many :students, through: :enrollments - Defines which students are associated with the course.

===UML Diagram===
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:10:11Z

Vshetty2: /* Design Goals */

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic:
* Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG]]

===Associations===

'''Notification'''

belongs_to :user - Links the notification to its creator (TA, instructor).

belongs_to :course - Links the notification to a course.

'''User'''

has_many :notifications - Users (instructors, TAs) can create multiple notifications.

has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

has_many :notifications - Each course can have multiple notifications.

has_many :students, through: :enrollments - Defines which students are associated with the course.

===UML Diagram===
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:09:44Z

Vshetty2: /* UML Diagram */

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic:
* Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
* Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG]]

===Associations===

'''Notification'''

belongs_to :user - Links the notification to its creator (TA, instructor).

belongs_to :course - Links the notification to a course.

'''User'''

has_many :notifications - Users (instructors, TAs) can create multiple notifications.

has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

has_many :notifications - Each course can have multiple notifications.

has_many :students, through: :enrollments - Defines which students are associated with the course.

===UML Diagram===
[[File:UML notification2.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

File:UML notification2.PNG

2024-11-11T23:09:30Z

Vshetty2:

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T23:00:49Z

Vshetty2:

__TOC__

==Objective==
To create a Notification model in the backend to handle notifications for the Expertiza system. This model will manage notifications for different courses and be accessible to students and instructors based on their association with a course. Notifications can have attributes such as subject, description, expiration date, and status (active/inactive).

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic:
* Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
* Implement the Notification backend: Implement the Notification in Ruby on Rails.

1. Model Creation:

Create a Notification model with the following key attributes:
* id: Primary key (auto-generated).
* subject: Brief title of the notification.
* description: Detailed message of the notification.
* expiration_date: The date when the notification should expire.
* is_active: Boolean flag to mark if the notification is active or inactive.
* is_unread: Boolean to mark if a notification is unread (default to true for new notifications).

2. Associations:

* Define associations between Notification, User, and Course models.
* User Association: Each notification should have a creator (e.g., a teaching assistant or instructor).
* Course Association: Each notification should be linked to a course, and the enrolled students should be able to view relevant notifications.

3. Relationships:

* One-to-Many: Course to Notification, as each course can have multiple notifications.
* One-to-Many: User (creator) to Notification, as a user can create multiple notifications.
* Many-to-Many (indirect): User to Notification via course enrollment, as multiple students can view a notification if they are enrolled in the course associated with the notification.

==Schema==
[[File:Schema2.PNG]]

===Associations===

'''Notification'''

belongs_to :user - Links the notification to its creator (TA, instructor).

belongs_to :course - Links the notification to a course.

'''User'''

has_many :notifications - Users (instructors, TAs) can create multiple notifications.

has_many :viewable_notifications, through: :courses - Students can view notifications for courses they are enrolled in.

'''Course'''

has_many :notifications - Each course can have multiple notifications.

has_many :students, through: :enrollments - Defines which students are associated with the course.

===UML Diagram===
[[File:UML notification.PNG| center]]

''' Relationship Explanation'''

* User to Notification: A User (e.g., TA, instructor) can create multiple notifications.
* Course to Notification: Each Course can have multiple notifications associated with it.
* User (Student) to Notification (Viewer): Through Course enrollment, students can access notifications related to their courses.

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

== Endpoints for Notification Management ==

Endpoints for Creating, Reading, Updating, and Deleting (CRUD) Notifications

1. POST /notifications - Create a new notification.

2. GET /notifications - Get a list of notifications (with optional filters, such as is_active or is_unread).

3. GET /notifications/ - View details of a specific notification.

4. PUT /notifications/ - Update a specific notification.

5. DELETE /notifications/ - Delete a specific notification.

=Design Pattern=

=Testing=

1. Model Tests:

* Validate presence and format of subject and description.
* Test is_active and is_unread default values.

2. Controller Tests:

* Ensure proper creation, update, and deletion of notifications.
* Test that only authorized users can manage notifications.

3. Integration Tests:

* Test access control to verify that only eligible users can view or manage notifications based on role and course association.

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T22:44:28Z

Vshetty2:

File:Schema2.PNG

2024-11-11T22:38:49Z

Vshetty2:

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T22:35:33Z

Vshetty2:

File:UML notification.PNG

2024-11-11T22:33:37Z

Vshetty2: Vshetty2 uploaded a new version of File:UML notification.PNG

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T22:22:17Z

Vshetty2:

CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model

2024-11-11T21:59:42Z

Vshetty2:

__TOC__

==Introduction==
This project is the implementation for the notification model and controller in the Expertiza backend.

==Requirements==
* Create a new Notification model with appropriate attributes and relationships:
* Define associations with User and Course models
* Implement scopes for filtering notifications based on roles
* Add validation rules for notification data
* Include timestamp fields for proper notification tracking
* Develop a NotificationsController with:
* Standard CRUD operations (create, read, update, delete)
* Role-based access control logic
* Course enrollment verification
* Proper error handling and response formatting
* RESTful API endpoints
* Implement authorization logic:
* Add policies to ensure students only see relevant notifications
* Write comprehensive test cases:
* Unit tests for the Notification model
* Controller tests covering all CRUD operations
* Integration tests for role-based access
* Test cases for error scenarios and edge cases

==Design Goals==
* Implement the Notification backend: Implement the Notification in Ruby on Rails.

==Schema==
* Each notification must be associated with a single course.
* Each course may or may not have notifications associated with it.
* Many notifications can be sent to many users.
* Many users can create/send many notifications.

===UML Diagram===
[[File:UML notification.PNG]]

==Implementation==

== ⁠issue, methods, problem, solution (rename later)==

=Design Pattern=

=Testing=

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu
* '''Aditi Killedar''' akilled@ncsu.edu

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

File:UML notification.PNG

2024-11-10T23:40:34Z

Vshetty2:

File:Schema.PNG

2024-11-10T23:22:49Z

Vshetty2:

CSC/ECE 517 Fall 2024

2024-11-09T23:38:27Z

Vshetty2:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]

CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification

2024-10-30T03:30:56Z

Vshetty2:

__TOC__

=About Expertiza=

[http://expertiza.ncsu.edu/ Expertiza], an open-source project built on Ruby on Rails, serves as a versatile learning management platform, enabling instructors to design and customize assignments. It facilitates collaborative learning by allowing students to select topics, form teams, and participate in peer reviews. Recently, the platform has expanded to incorporate modern frontend technologies, with components being refactored to use React.js and Typescript. This upgrade enhances the user experience, making the interface more interactive and responsive while supporting submissions in multiple formats, including URLs and wiki pages, for seamless review and evaluation.

=Issues with previous Functionality=
* The prior implementation effectively created user interfaces for managing roles and institutions but missed certain critical specifications.
* The project was not merged due to unnecessary dynamic role creation; only administrators required the ability to add roles, so this feature was removed to simplify the design.
* The institution management interface lacked proper authorization, allowing all users access to manage institutions, which conflicted with intended role-based permissions.

=Design Goals=
* Modernize the Frontend: Re-implement the existing Institutions UI from Ruby on Rails to TypeScript and ReactJS for improved modularity, performance, and maintainability.

* Authorization-Optimized UIs: Ensure role-based access by allowing only designated roles (e.g., TAs, Instructors) to manage specific functionalities in Institutions and Notifications.

* Enhanced Notifications Feature: Introduce a robust notification management system that enables course-specific notifications creation for higher roles and displays relevant notifications to enrolled students.

* Toggle and Filter Options: Implement a toggle for notifications to control active/inactive status and filter notifications for students to display only active, course-relevant alerts.

=Implementation=

=== Enhanced the Manage Institutions page UI ===

Improved the layout and styling of the Manage Institutions page to provide a more user-friendly interface. Adjusted table centering, optimized spacing, and updated visual elements for better alignment and readability.
[[File:Manage institutions.PNG|center|800px]]

===Added authorization for Institutions [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/0eb2a19b2aa2454f4e5e51b3a02afd28ec79e63c commit]===

Implemented role-based access control to ensure only users with Instructor or higher roles can manage institutions, aligning permissions with user roles and preventing unauthorized access.
[[File: Authentication for institution.PNG|center|800px]]

===Added Manage Notifications Page [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/de6b0d635cc1a0446928dbe7c838be3ad913f73d commit]===

Developed a dedicated page where authorized users, such as TAs and Instructors, can create, edit, and delete course-specific notifications to streamline communication and course updates.
[[File:Manage notifications.PNG|center|800px]]
Following pop-up window appears on clicking create button. the Close/ Create Notification button will redirect to the Manage Notifications page.
[[File:Manage notifications - create.png|center|800px]]
Following pop-up window appears on clicking edit button for an existing notification. the Close/ Update Notification button will redirect to the Manage Notifications page.
[[File:Manage notifications - update.png|center|800px]]
Following pop-up window appears on clicking delete button. the Delete button will redirect to the Manage Notifications page and dispatch an alert message on top of the page that the notification was deleted successfully.
[[File:Manage notifications - delete.png|center|800px]]

===Added My Notifications Page [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/c998ced0962c1d786d5e137c638f9cf051488e20 commit]===

Created a page for students to view relevant, active notifications for courses they are enrolled in, ensuring they receive timely updates on assignments, exams, and other course events.
[[File:My notifications.PNG|center|800px]]

===Added Toggle Notification Feature [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/d341cdfea89b85a24fb5c9be4340981b46bccba5 commit]===

Implemented a toggle option for authorized users to activate or deactivate notifications, allowing control over the visibility of notifications for students based on course requirements.
[[File:Toggle notifications.PNG|center|300px]]

===Added Notification Badge [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/a66f55a3907c6bf969a2b1751624cf81ab353583 commit]===

Introduced a notification badge on the "My Notifications" menu item, displaying the count of new or unread notifications to keep users informed of recent updates at a glance.
[[File:Notification badge.PNG|center|600px]]

===Added Alert on Home Page===

Implemented an alert on the home page to notify users of any unread notifications upon login, ensuring important updates are immediately visible.
[[File:Notification Alert.PNG|center|900px]]

=Design Pattern=

1. Container-Presenter Pattern

Container components are responsible for managing the logic, data fetching, and application state.
Presenter components (also known as Dumb Components) focus on rendering UI elements based on the props received from the container. They don’t manage state or handle business logic directly; instead, they rely on the container for data.

*Institutions and Notifications as Container Components:
**In Institutions.tsx and Notifications.tsx, the primary components act as containers.
**Load the required data using the useLoaderData hook (e.g., fetching institution and notification data).
**Handle logic and user interactions (e.g., onEditHandle and onDeleteHandle for editing and deleting institutions/notifications).
**Handle the permissions and authorization checks, showing different options based on user roles.

*UI Table and Actions as Presenter Components:
**Components such as the Table component and column definitions in institutionColumns.tsx and notificationColumns.tsx act as presenters.
**The presenters don’t hold business logic or directly manage state; they simply render the data provided by the container components.
**For instance:
**The Table component renders the list of institutions/notifications.
**notificationColumns and institutionColumns define the columns, actions, and structure without managing the actual data or state.

 2. Strategy Pattern 
Used in a Limited Form: The Strategy pattern is partially used here in how we pass callback functions (handleEdit and handleDelete) to the column definitions for the table. These functions define the “strategy” for how each action should be handled, allowing flexibility without modifying the notificationColumns or institutionColumns structures.

*Implementation Detail: By passing these functions as arguments, we can customize the behavior for different actions (like editing or deleting) based on the page context. This approach allows us to define different behaviors without altering the column setup, which is a core aspect of the Strategy pattern.

=Testing=
Added mock data for verifying the pages are rendered as expected. There is currently no backend implemented, so the tests does not involve calling relevant API endpoints; this will be considered as future work.
[[File:mock data.png|center|800px]]
Following is the video demonstrating the UI workflows. Since this is a UI project, the functionality is tested manually.
* '''Test Video Link:''' https://youtu.be/h7CiRxTgctA

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu

=Relevant Links=
* '''Github Repository:''' https://github.com/SoubarnicaSuresh/reimplementation-front-end
* '''Pull Request:''' https://github.com/expertiza/reimplementation-front-end/pull/67

CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification

2024-10-30T03:18:25Z

Vshetty2:

__TOC__

=About Expertiza=

[http://expertiza.ncsu.edu/ Expertiza], an open-source project built on Ruby on Rails, serves as a versatile learning management platform, enabling instructors to design and customize assignments. It facilitates collaborative learning by allowing students to select topics, form teams, and participate in peer reviews. Recently, the platform has expanded to incorporate modern frontend technologies, with components being refactored to use React.js and Typescript. This upgrade enhances the user experience, making the interface more interactive and responsive while supporting submissions in multiple formats, including URLs and wiki pages, for seamless review and evaluation.

=Issues with previous Functionality=
* The prior implementation effectively created user interfaces for managing roles and institutions but missed certain critical specifications.
* The project was not merged due to unnecessary dynamic role creation; only administrators required the ability to add roles, so this feature was removed to simplify the design.
* The institution management interface lacked proper authorization, allowing all users access to manage institutions, which conflicted with intended role-based permissions.

=Design Goals=
* Modernize the Frontend: Re-implement the existing Institutions UI from Ruby on Rails to TypeScript and ReactJS for improved modularity, performance, and maintainability.

* Authorization-Optimized UIs: Ensure role-based access by allowing only designated roles (e.g., TAs, Instructors) to manage specific functionalities in Institutions and Notifications.

* Enhanced Notifications Feature: Introduce a robust notification management system that enables course-specific notifications creation for higher roles and displays relevant notifications to enrolled students.

* Toggle and Filter Options: Implement a toggle for notifications to control active/inactive status and filter notifications for students to display only active, course-relevant alerts.

=Implementation=

=== Enhanced the Manage Institutions page UI ===

Improved the layout and styling of the Manage Institutions page to provide a more user-friendly interface. Adjusted table centering, optimized spacing, and updated visual elements for better alignment and readability.
[[File:Manage institutions.PNG|center|800px]]

===Added authorization for Institutions [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/0eb2a19b2aa2454f4e5e51b3a02afd28ec79e63c commit]===

Implemented role-based access control to ensure only users with Instructor or higher roles can manage institutions, aligning permissions with user roles and preventing unauthorized access.
[[File: Authentication for institution.PNG|center|800px]]

===Added Manage Notifications Page [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/de6b0d635cc1a0446928dbe7c838be3ad913f73d commit]===

Developed a dedicated page where authorized users, such as TAs and Instructors, can create, edit, and delete course-specific notifications to streamline communication and course updates.
[[File:Manage notifications.PNG|center|800px]]
Following pop-up window appears on clicking create button. the Close/ Create Notification button will redirect to the Manage Notifications page.
[[File:Manage notifications - create.png|center|800px]]
Following pop-up window appears on clicking edit button for an existing notification. the Close/ Update Notification button will redirect to the Manage Notifications page.
[[File:Manage notifications - update.png|center|800px]]
Following pop-up window appears on clicking delete button. the Delete button will redirect to the Manage Notifications page and dispatch an alert message on top of the page that the notification was deleted successfully.
[[File:Manage notifications - delete.png|center|800px]]

===Added My Notifications Page [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/c998ced0962c1d786d5e137c638f9cf051488e20 commit]===

Created a page for students to view relevant, active notifications for courses they are enrolled in, ensuring they receive timely updates on assignments, exams, and other course events.
[[File:My notifications.PNG|center|800px]]

===Added Toggle Notification Feature [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/d341cdfea89b85a24fb5c9be4340981b46bccba5 commit]===

Implemented a toggle option for authorized users to activate or deactivate notifications, allowing control over the visibility of notifications for students based on course requirements.
[[File:Toggle notifications.PNG|center|300px]]

===Added Notification Badge [https://github.com/SoubarnicaSuresh/reimplementation-front-end/commit/a66f55a3907c6bf969a2b1751624cf81ab353583 commit]===

Introduced a notification badge on the "My Notifications" menu item, displaying the count of new or unread notifications to keep users informed of recent updates at a glance.
[[File:Notification badge.PNG|center|600px]]

===Added Alert on Home Page===

Implemented an alert on the home page to notify users of any unread notifications upon login, ensuring important updates are immediately visible.
[[File:Notification Alert.PNG|center|900px]]

=Testing=
Added mock data for verifying the pages are rendered as expected. There is currently no backend implemented, so the tests does not involve calling relevant API endpoints; this will be considered as future work.
[[File:mock data.png|center|800px]]
Following is the video demonstrating the UI workflows. Since this is a UI project, the functionality is tested manually.
* '''Test Video Link:''' https://youtu.be/h7CiRxTgctA

=Team=
Mentor Jay Patel : jhpatel9@ncsu.edu

* '''Vaibhavi Shetty:''' vshetty2@ncsu.edu
* '''Soubarnica Suresh''' ssomang@ncsu.edu

=Relevant Links=
* '''Github Repository:''' https://github.com/SoubarnicaSuresh/reimplementation-front-end
* '''Pull Request:''' https://github.com/expertiza/reimplementation-front-end/pull/67

CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification

2024-10-29T20:48:50Z

Vshetty2:

File:Notification Alert.PNG

2024-10-29T20:35:00Z

Vshetty2:

File:Notification badge.PNG

2024-10-29T20:33:21Z

Vshetty2:

File:My notifications.PNG

2024-10-29T20:32:04Z

Vshetty2:

File:Toggle notifications.PNG

2024-10-29T20:28:20Z

Vshetty2:

File:Manage notifications.PNG

2024-10-29T20:25:29Z

Vshetty2:

File:Manage institutions.PNG

2024-10-29T20:10:45Z

Vshetty2:

File:Authentication for institution.PNG

2024-10-29T19:33:18Z

Vshetty2:

File:NC State.jpg

2024-10-29T18:36:53Z

Vshetty2:

CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification

2024-10-29T06:03:52Z

Vshetty2:

CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification

2024-10-28T04:25:21Z

Vshetty2: Created page with " __TOC__ ==About Expertiza== [http://expertiza.ncsu.edu/ Expertiza], an open-source project built on Ruby on Rails, serves as a versatile learning management platform, enabling instructors to design and customize assignments. It facilitates collaborative learning by allowing students to select topics, form teams, and participate in peer reviews. Recently, the platform has expanded to incorporate modern frontend technologies, with components being refactored to use Reac..."

__TOC__

==About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza], an open-source project built on Ruby on Rails, serves as a versatile learning management platform, enabling instructors to design and customize assignments. It facilitates collaborative learning by allowing students to select topics, form teams, and participate in peer reviews. Recently, the platform has expanded to incorporate modern frontend technologies, with components being refactored to use React.js and Typescript. This upgrade enhances the user experience, making the interface more interactive and responsive while supporting submissions in multiple formats, including URLs and wiki pages, for seamless review and evaluation.

CSC/ECE 517 Fall 2024

2024-10-28T03:40:34Z

Vshetty2:

* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]