Expertiza_Wiki - User contributions [en]

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

2024-12-04T16:17:25Z

Akilled: /* Schema */

__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:NewSchema.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 Notif.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]

File:NewSchema.png

2024-12-04T16:17:15Z

Akilled:

File:Schema2.PNG

2024-12-04T16:15:51Z

Akilled: Akilled uploaded a new version of File:Schema2.PNG

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

2024-12-04T16:12:11Z

Akilled: /* UML Diagram */

__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 Notif.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]

File:UML Notif.png

2024-12-04T16:11:53Z

Akilled:

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

2024-12-04T04:58:37Z

Akilled: /* 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.

== 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''' []

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

2024-12-04T04:58:05Z

Akilled: Undo revision 160689 by Akilled (talk)

__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.

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''' []

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

2024-12-04T04:57:47Z

Akilled: /* 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.

== 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.

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
before(:each) do
# Mock the course and user
@course = instance_double(Course, name: "Ruby 101")
role = instance_double(Role, id: 1, name: "Student")
@user = instance_double(User, id: 1, name: "Test User", email: "test@example.com", role: role)
end

describe 'validations' do
it 'is invalid without a subject' do
notification = Notification.new(subject: nil)
expect(notification).not_to be_valid
expect(notification.errors[:subject]).to include("can't be blank")
end

it 'is invalid without a description' do
notification = Notification.new(description: nil)
expect(notification).not_to be_valid
expect(notification.errors[:description]).to include("can't be blank")
end

it 'is invalid without an expiration_date' do
notification = Notification.new(expiration_date: nil)
expect(notification).not_to be_valid
expect(notification.errors[:expiration_date]).to include("can't be blank")
end

it 'is invalid if expiration_date is in the past' do
notification = Notification.new(expiration_date: Date.yesterday)
expect(notification).not_to be_valid
expect(notification.errors[:expiration_date]).to include("cannot be in the past")
end
end

describe 'associations' do
it 'belongs to a course' do
# Mock the course association
notification = Notification.new
allow(notification).to receive(:course).and_return(@course)

# Test that the association returns the mocked course
expect(notification.course).to eq(@course)
end

it 'belongs to a user' do
# Mock the user association
notification = Notification.new
allow(notification).to receive(:user).and_return(@user)

# Test that the association returns the mocked user
expect(notification.user).to eq(@user)
end
end

describe 'scopes' do
before(:each) do
@notification1 = instance_double(
Notification,
subject: "Active Notification",
expiration_date: Date.today + 3,
active_flag: true,
course_name: @course.name,
user: @user
)

@notification2 = instance_double(
Notification,
subject: "Expired Notification",
expiration_date: Date.yesterday,
active_flag: true,
course_name: @course.name,
user: @user
)

@notification3 = instance_double(
Notification,
subject: "Inactive Notification",
expiration_date: Date.today + 7,
active_flag: false,
course_name: @course.name,
user: @user
)
end

describe '.active' do
it 'returns notifications that are active' do
allow(Notification).to receive(:active).and_return([@notification1])
expect(Notification.active).to include(@notification1)
expect(Notification.active).not_to include(@notification2, @notification3)
end
end

describe '.expired' do
it 'returns notifications that are expired' do
allow(Notification).to receive(:expired).and_return([@notification2])
expect(Notification.expired).to include(@notification2)
expect(Notification.expired).not_to include(@notification1, @notification3)
end
end

describe '.unread_by' do
it 'returns notifications that are unread by the user' do
allow(Notification).to receive(:unread_by).with(@user).and_return([@notification1])
unread_notifications = Notification.unread_by(@user)
expect(unread_notifications).to include(@notification1)
expect(unread_notifications).not_to include(@notification2, @notification3)
end
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''' []

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

2024-12-04T04:56:26Z

Akilled: /* 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.

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''' []

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

2024-12-04T04:56:04Z

Akilled: /* Design Pattern */

__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.

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-12-04T04:55:18Z

Akilled: /* Design Pattern */

__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 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.

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-12-04T04:53:38Z

Akilled: /* New Files */

__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 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-12-04T04:52:25Z

Akilled: /* New Files */

__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) 

<a href=https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/app/models/notification.rb>Commit </a>

<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) 

<a href=https://github.com/SoubarnicaSuresh/reimplementation-back-end/blob/main/app/controllers/api/v1/notifications_controller.rb>Commit</a>

<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 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-12-04T04:51:14Z

Akilled: /* New Files */

__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) 

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

<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) 

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

<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 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-12-04T04:50:27Z

Akilled: /* New Files */

__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) 

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

<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) 

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

<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 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-12-04T04:48:20Z

Akilled: /* New Files */

__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) 

<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) 

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

== 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-12-04T04:46:27Z

Akilled: /* New Files */

__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) 

<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) 

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

 3. Spec for Controller (spec/requests/api/v1/notification_controller.rb) 

require 'swagger_helper'

RSpec.describe 'Notifications API', type: :request do
let(:user) { create(:user, name: 'test_user') }
let(:course) { create(:course, name: 'Ruby 101', instructor_id: user.id, institution_id: 1) }
let(:notification) { create(:notification, course: course, user: user, subject: 'Test Notification') }

path '/api/v1/notifications' do
get('list notifications') do
tags 'Notifications'
produces 'application/json'

response(200, 'Success') do
let!(:notifications) { create_list(:notification, 5, user: user, course: course) }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do |response|
expect(JSON.parse(response.body).size).to eq(5)
end
end
end

post('create 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 },
active_flag: { type: :boolean },
course_id: { type: :integer }
},
required: %w[subject course_id]
}

response(201, 'Created') do
let(:notification) { { subject: 'New Notification', description: 'Details', expiration_date: Date.today + 7, course_id: course.id } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(422, 'Unprocessable Entity') do
let(:notification) { { description: 'Details', expiration_date: Date.today + 7, course_id: course.id } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end

path '/api/v1/notifications/{id}' do
parameter name: :id, in: :path, type: :integer, description: 'ID of the notification'

get('show notification') do
tags 'Notifications'
response(200, 'Success') do
let(:id) { notification.id }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

patch('update 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 },
active_flag: { type: :boolean }
}
}

response(200, 'Updated') do
let(:id) { notification.id }
let(:notification) { { subject: 'Updated Notification', active_flag: true } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }
let(:notification) { { subject: 'Updated Notification', active_flag: true } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

delete('delete notification') do
tags 'Notifications'

response(204, 'Deleted') do
let(:id) { notification.id }
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end

path '/api/v1/notifications/{id}/toggle_active' do
parameter name: :id, in: :path, type: :integer, description: 'ID of the notification'

patch('toggle notification visibility') do
tags 'Notifications'

response(200, 'Visibility toggled') do
let(:id) { notification.id }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
end

 4. Tests for Model (spec/models/notification_spec.rb)

require 'rails_helper'

RSpec.describe Notification, type: :model do
before(:each) do
# Mock the course and user
@course = instance_double(Course, name: "Ruby 101")
role = instance_double(Role, id: 1, name: "Student")
@user = instance_double(User, id: 1, name: "Test User", email: "test@example.com", role: role)
end

describe 'validations' do
it 'is invalid without a subject' do
notification = Notification.new(subject: nil)
expect(notification).not_to be_valid
expect(notification.errors[:subject]).to include("can't be blank")
end

it 'is invalid without a description' do
notification = Notification.new(description: nil)
expect(notification).not_to be_valid
expect(notification.errors[:description]).to include("can't be blank")
end

it 'is invalid without an expiration_date' do
notification = Notification.new(expiration_date: nil)
expect(notification).not_to be_valid
expect(notification.errors[:expiration_date]).to include("can't be blank")
end

it 'is invalid if expiration_date is in the past' do
notification = Notification.new(expiration_date: Date.yesterday)
expect(notification).not_to be_valid
expect(notification.errors[:expiration_date]).to include("cannot be in the past")
end
end

describe 'associations' do
it 'belongs to a course' do
# Mock the course association
notification = Notification.new
allow(notification).to receive(:course).and_return(@course)

# Test that the association returns the mocked course
expect(notification.course).to eq(@course)
end

it 'belongs to a user' do
# Mock the user association
notification = Notification.new
allow(notification).to receive(:user).and_return(@user)

# Test that the association returns the mocked user
expect(notification.user).to eq(@user)
end
end

describe 'scopes' do
before(:each) do
@notification1 = instance_double(
Notification,
subject: "Active Notification",
expiration_date: Date.today + 3,
active_flag: true,
course_name: @course.name,
user: @user
)

@notification2 = instance_double(
Notification,
subject: "Expired Notification",
expiration_date: Date.yesterday,
active_flag: true,
course_name: @course.name,
user: @user
)

@notification3 = instance_double(
Notification,
subject: "Inactive Notification",
expiration_date: Date.today + 7,
active_flag: false,
course_name: @course.name,
user: @user
)
end

describe '.active' do
it 'returns notifications that are active' do
allow(Notification).to receive(:active).and_return([@notification1])
expect(Notification.active).to include(@notification1)
expect(Notification.active).not_to include(@notification2, @notification3)
end
end

describe '.expired' do
it 'returns notifications that are expired' do
allow(Notification).to receive(:expired).and_return([@notification2])
expect(Notification.expired).to include(@notification2)
expect(Notification.expired).not_to include(@notification1, @notification3)
end
end

describe '.unread_by' do
it 'returns notifications that are unread by the user' do
allow(Notification).to receive(:unread_by).with(@user).and_return([@notification1])
unread_notifications = Notification.unread_by(@user)
expect(unread_notifications).to include(@notification1)
expect(unread_notifications).not_to include(@notification2, @notification3)
end
end
end
end

== 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-12-04T04:45:52Z

Akilled: /* New Files */

__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) 

<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)

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

3. Spec for Controller (spec/requests/api/v1/notification_controller.rb)

require 'swagger_helper'

RSpec.describe 'Notifications API', type: :request do
let(:user) { create(:user, name: 'test_user') }
let(:course) { create(:course, name: 'Ruby 101', instructor_id: user.id, institution_id: 1) }
let(:notification) { create(:notification, course: course, user: user, subject: 'Test Notification') }

path '/api/v1/notifications' do
get('list notifications') do
tags 'Notifications'
produces 'application/json'

response(200, 'Success') do
let!(:notifications) { create_list(:notification, 5, user: user, course: course) }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do |response|
expect(JSON.parse(response.body).size).to eq(5)
end
end
end

post('create 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 },
active_flag: { type: :boolean },
course_id: { type: :integer }
},
required: %w[subject course_id]
}

response(201, 'Created') do
let(:notification) { { subject: 'New Notification', description: 'Details', expiration_date: Date.today + 7, course_id: course.id } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(422, 'Unprocessable Entity') do
let(:notification) { { description: 'Details', expiration_date: Date.today + 7, course_id: course.id } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end

path '/api/v1/notifications/{id}' do
parameter name: :id, in: :path, type: :integer, description: 'ID of the notification'

get('show notification') do
tags 'Notifications'
response(200, 'Success') do
let(:id) { notification.id }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

patch('update 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 },
active_flag: { type: :boolean }
}
}

response(200, 'Updated') do
let(:id) { notification.id }
let(:notification) { { subject: 'Updated Notification', active_flag: true } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }
let(:notification) { { subject: 'Updated Notification', active_flag: true } }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

delete('delete notification') do
tags 'Notifications'

response(204, 'Deleted') do
let(:id) { notification.id }
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end

path '/api/v1/notifications/{id}/toggle_active' do
parameter name: :id, in: :path, type: :integer, description: 'ID of the notification'

patch('toggle notification visibility') do
tags 'Notifications'

response(200, 'Visibility toggled') do
let(:id) { notification.id }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end

response(404, 'Not Found') do
let(:id) { 'INVALID' }

after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
end

 4. Tests for Model (spec/models/notification_spec.rb)

require 'rails_helper'

RSpec.describe Notification, type: :model do
before(:each) do
# Mock the course and user
@course = instance_double(Course, name: "Ruby 101")
role = instance_double(Role, id: 1, name: "Student")
@user = instance_double(User, id: 1, name: "Test User", email: "test@example.com", role: role)
end

describe 'validations' do
it 'is invalid without a subject' do
notification = Notification.new(subject: nil)
expect(notification).not_to be_valid
expect(notification.errors[:subject]).to include("can't be blank")
end

it 'is invalid without a description' do
notification = Notification.new(description: nil)
expect(notification).not_to be_valid
expect(notification.errors[:description]).to include("can't be blank")
end

it 'is invalid without an expiration_date' do
notification = Notification.new(expiration_date: nil)
expect(notification).not_to be_valid
expect(notification.errors[:expiration_date]).to include("can't be blank")
end

it 'is invalid if expiration_date is in the past' do
notification = Notification.new(expiration_date: Date.yesterday)
expect(notification).not_to be_valid
expect(notification.errors[:expiration_date]).to include("cannot be in the past")
end
end

describe 'associations' do
it 'belongs to a course' do
# Mock the course association
notification = Notification.new
allow(notification).to receive(:course).and_return(@course)

# Test that the association returns the mocked course
expect(notification.course).to eq(@course)
end

it 'belongs to a user' do
# Mock the user association
notification = Notification.new
allow(notification).to receive(:user).and_return(@user)

# Test that the association returns the mocked user
expect(notification.user).to eq(@user)
end
end

describe 'scopes' do
before(:each) do
@notification1 = instance_double(
Notification,
subject: "Active Notification",
expiration_date: Date.today + 3,
active_flag: true,
course_name: @course.name,
user: @user
)

@notification2 = instance_double(
Notification,
subject: "Expired Notification",
expiration_date: Date.yesterday,
active_flag: true,
course_name: @course.name,
user: @user
)

@notification3 = instance_double(
Notification,
subject: "Inactive Notification",
expiration_date: Date.today + 7,
active_flag: false,
course_name: @course.name,
user: @user
)
end

describe '.active' do
it 'returns notifications that are active' do
allow(Notification).to receive(:active).and_return([@notification1])
expect(Notification.active).to include(@notification1)
expect(Notification.active).not_to include(@notification2, @notification3)
end
end

describe '.expired' do
it 'returns notifications that are expired' do
allow(Notification).to receive(:expired).and_return([@notification2])
expect(Notification.expired).to include(@notification2)
expect(Notification.expired).not_to include(@notification1, @notification3)
end
end

describe '.unread_by' do
it 'returns notifications that are unread by the user' do
allow(Notification).to receive(:unread_by).with(@user).and_return([@notification1])
unread_notifications = Notification.unread_by(@user)
expect(unread_notifications).to include(@notification1)
expect(unread_notifications).not_to include(@notification2, @notification3)
end
end
end
end

== 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-12-04T04:37:52Z

Akilled: /* New Files */

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

2024-12-04T04:37:02Z

Akilled: /* New Files */

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

2024-12-04T04:36:38Z

Akilled: Undo revision 160659 by Akilled (talk)

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

2024-12-04T04:35:34Z

Akilled: /* New Files */

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

2024-12-04T04:33:23Z

Akilled:

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

2024-11-17T22:43:29Z

Akilled: /* Objective */

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

2024-11-17T22:41:18Z

Akilled: /* Details about the Notification Model and Controller */

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

2024-11-17T22:31:33Z

Akilled:

__TOC__

==Details about the Notification Model and Controller==

==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==
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. Observer Pattern

* Use Case:
** Automatically notify users (e.g., students enrolled in a course) whenever a new notification is created or updated.
** This ensures users are always informed about important updates without requiring manual intervention.
* Explanation:
** The Notification model acts as the subject, and the students (or their respective notification systems) are observers.
** When a notification is created or updated, all observers are automatically notified through an after_commit callback.
** This pattern decouples the logic for creating notifications from the logic for notifying users, making the system easier to maintain and extend.

2. Factory Pattern

* Use Case:
** Creating different types of notifications (e.g., course notifications, system notifications, global announcements) with varying attributes or behaviors.
** This centralizes the creation logic and ensures consistency in object instantiation.
* Explanation:
** The factory centralizes the creation logic, making it easy to add new notification types in the future.
** It also reduces clutter in the controller by abstracting the instantiation process.

3. 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.

4. 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.

5. Command Pattern

* Use Case:
** Encapsulating the logic for sending notifications (e.g., emails, in-app alerts) into discrete, reusable objects.
** Useful for task queuing or asynchronous operations.
* Explanation:
** The Command Pattern encapsulates the logic for sending notifications, making it easier to queue or log these operations.
** It improves code reusability and separation of concerns.

6. Template Method Pattern

* Use Case:
** Defining a common process for creating notifications while allowing specific steps to be overridden for different types of notifications (e.g., course notifications vs. global announcements).
* Explanation:
** The Template Method Pattern enforces a consistent process for creating notifications while allowing flexibility for specific steps.
** This ensures uniformity across different notification types.

7. 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.

8. 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.

=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:''' [https://github.com/SoubarnicaSuresh/reimplementation-back-end reimplementation back-end]

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

2024-11-10T22:26:19Z

Akilled: /* Design Goals */

__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===
<goes here>

==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:'''

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

2024-11-10T22:22:15Z

Akilled: /* Schema Diagram */ Reasoning behind UML Diagram

__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==
* Modernize the Frontend: Re-implement the existing Institutions UI from Ruby on Rails to TypeScript and ReactJS for improved modularity, performance, and maintainability.

==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===
<goes here>

==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:'''

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

2024-11-10T22:15:00Z

Akilled:

__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==
* Modernize the Frontend: Re-implement the existing Institutions UI from Ruby on Rails to TypeScript and ReactJS for improved modularity, performance, and maintainability.

==Schema Diagram==

==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:'''

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

2024-11-10T22:09:46Z

Akilled:

__TOC__

==Introduction==

=About Expertiza=

==Requirements==

=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.

==Schema Diagram==

=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:'''

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

2024-11-10T21:14:14Z

Akilled: Created page with " __TOC__ ==Introduction== =About Expertiza= ==Requirements== =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. ==Schema Diagram== =Implementation= == ⁠issue, methods, problem, solution (rename later)== =Design Pattern= =Testing= =Team= Mentor Jay Patel : jhpatel9@ncsu.edu * '''Vaibhavi Shetty:''' vshetty2@n..."

__TOC__

==Introduction==

=About Expertiza=

==Requirements==

=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.

==Schema Diagram==

=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

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

CSC/ECE 517 Fall 2024 - E2463 Implement Front End for Student Task List

2024-10-30T01:14:18Z

Akilled:

== Expertiza ==
Expertiza is an open-source learning management system primarily developed with Ruby on Rails. It offers features such as creating tests and assignments, managing teams and courses, and, most importantly, providing a robust framework for peer reviews and group feedback. This project focuses on developing frontend components in React, with an emphasis on the Student Task list page. The aim is to build a fully operational user interface for these components using React.js and TypeScript.

== Introduction ==
The main objective of this project is to implement the front end for the Student Task list page within Expertiza.

== Project Description ==

===Objective===
This project’s goal is to redesign the front end of the current non-TypeScript Student Task List page on Expertiza by building a new user interface with React.js and TypeScript, ensuring a more type-safe development experience. The page will showcase all assignments the user is involved in, requiring data fetching to obtain the assignment list, filtering based on the user’s participation, and presenting the results in a visually engaging, user-friendly format through React components.
This is the visual framework for creating the user interface:

[[File: Flow_Chart_Student_tasks.jpg | 1000px]] 

===Development Steps===
*Review Current Interface: Conduct a detailed analysis of the existing Ruby on Rails UI to understand its layout and features.
*Setup Development Environment: Configure the environment to work with TypeScript and React.
*Design Components: Break down the UI into distinct React components, defining the props and states needed for each.
*Implement in Typescript: Develop the component logic in TypeScript, prioritizing type safety.
*Replicate Functionality: Ensure all features from the Rails application are mirrored in the React components, maintaining full functionality.
*Styling and Add Interactivity: Style components and integrate interactive elements using CSS.
*Testing: Perform individual component testing and end-to-end testing for the entire application.

== Design ==
===Current Implementation (Ruby on Rails)===

The existing interface on Expertiza, developed with Ruby on Rails, displays a student's task list with assignments, due dates, and progress indicators.

 Current Implementation of Expertiza with Ruby on Rails 
[[File:Expertiza_current_implementation.jpg | 1000px]]

===New Implementation (React JS & TypeScript)===

Our updated UI replicates the functionality of the original page, now leveraging TypeScript's reliability alongside React's dynamic rendering. We prioritized building a responsive, accessible interface that aligns with modern design principles. We have also included certain features to make it easy for the student to manage their assignments. 
 Implementation Overview 

[[File: New_Implementation_Assignments_Page.jpg | 1000px ]] 

1. Fetch and Display Data: The UI is designed with future live data integration in mind. Currently, we use structured placeholder data to mimic backend interactions.

Implementation Steps
*Defined TypeScript interfaces to model assignment data structures.
*Created mock data to simulate API responses for development.

2. React Component Design: We developed modular React components like Header, TaskList, and TaskItem to improve code reusability and maintainability.

 Legend 

We have included a legend on the right of the student task list, to improve clarity, allowing users to understand column meanings at a glance. This approach is more user-friendly than requiring users to hover over a small info icon, and it provides a cleaner, more streamlined interface.

Implementation Steps
==== StudentTasksBox component ====
*Implementation of the StudentTasksBox component - [https://github.com/aditikilledar/reimplementation-front-end/blob/student-tasks-ui-f24/src/pages/StudentTasks/StudentTasksBox.tsx] 

<syntaxhighlight>
const StudentTasksBox: React.FC<StudentTasksBoxProps> = ({ participantTasks, revisions, studentsTeamedWith }) => {
// Calculate total number of students teamed up with by iterating over each semester
let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

// Calculate the number of revisions that are still pending (i.e., due date is in the future)
const pendingRevisions = revisions.filter(revision => getDaysLeft(revision.dueDate) > 0);

const dueTasks = participantTasks.filter(task => getDaysLeft(task.stageDeadline) > 0);

// Group tasks by course
const tasksByCourse: { [key: string]: typeof participantTasks } = {};

dueTasks.forEach(task => {
const courseName = task.course;

if (!tasksByCourse[courseName]) {
tasksByCourse[courseName] = [];
}

tasksByCourse[courseName].push(task);
});

return (
<div className={styles.container}>
<h2>Task Summary</h2>
<div className={styles.infoBox}>
<h5>Due:</h5>
{Object.entries(tasksByCourse).map(([course, tasks]) => (
<div key={course}>
{course}
<ul>
{tasks.map(task => (
<li key={task.id}>
{task.assignment} - Due: {task.stageDeadline}
</li>
))}
</ul>
</div>
))}
</div>

<div className={styles.infoBox}>
<h5>Revisions:</h5>
<ul>
{revisions.map((revision, index) => (
<li key={index}>{revision.name}</li>
))}
</ul>
</div>

<div className={styles.infoBox}>
<div className={styles.teamedStudents}>
<h5>Total Students Teamed With: {totalStudents}</h5>
<ul>
{allStudents.map((student, index) => (
<li key={index}>{student}</li>
))}
</ul>
</div>
</div>
</div>
);

};
</syntaxhighlight> 

New UI for StudentTasksBox Component 

[[File: StudentTasksBox_Task Summary.jpg | 200px]]
[[File: StudentTasksBox_Revisions and Students Teamed With.jpg | 200px]] 

==== StudentTaskHome component ====
*Implementation of the StudentTaskHome component that handles the list of assignments along with filters (dropdowns). [https://github.com/aditikilledar/reimplementation-front-end/blob/student-tasks-ui-f24/src/pages/StudentTasks/StudentTaskHome.tsx] 
<syntaxhighlight>
const StudentTasksHome: React.FC = () => {
// init state and hooks
const currUserId = testData.current_user_id;
const dispatch = useDispatch();
const navigate = useNavigate();
const auth = useSelector((state: RootState) => state.authentication)

type StudentsTeamedWith = {
[semester: string]: string[];
};

// states to hold tasks
const taskRevisions = testData.revisions;
const participantTasks = testData.participantTasks;
console.log("participantTasks", participantTasks)

const [tasks, setTasks] = useState<Task[]>([]);
const dueTasks = testData.dueTasks;
const studentsTeamedWith: StudentsTeamedWith = testData.studentsTeamedWith;
const [filteredTasks, setFilteredTasks] = useState<Task[]>([]);

const [assignmentFilter, setAssignmentFilter] = useState('');
const [courseFilter, setCourseFilter] = useState('');
const [topicFilter, setTopicFilter] = useState('');
const [currentstageFilter, setCurrentStageFilter] = useState('');

function togglePublishingRights(id: number): void {
throw new Error('Function not implemented.');
}

let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

useEffect(() => {
// Map the data from participationTasks to the tasks state
const mappedTasks = participantTasks.map(task => ({
id: task.id,
assignment: task.assignment,
course: task.course,
topic: task.topic,
currentStage: task.current_stage, // Adjust to match your data's structure
reviewGrade: task.review_grade, // Can be a string or an object
badges: task.badges, // Keep as is since it can be string or boolean
stageDeadline: task.stage_deadline, // Adjust to match your data's structure
publishingRights: task.publishing_rights, // Boolean type
}));

setTasks(mappedTasks);
setFilteredTasks(mappedTasks);
}, [participantTasks]);

console.log("after use effect:", participantTasks)

useEffect(() => {
const filtered = tasks.filter((task) =>
(assignmentFilter ? task.assignment === assignmentFilter : true) &&
(courseFilter ? task.course === courseFilter : true) &&
(topicFilter ? task.topic === topicFilter : true) &&
(currentstageFilter ? task.topic == currentstageFilter : true)
);
setFilteredTasks(filtered);
}, [assignmentFilter, courseFilter, topicFilter, currentstageFilter, tasks]);
</syntaxhighlight>

New UI for StudentTaskHome Component 
[[File: StudentTaskHome.jpg | 1000px ]] 

3. Table Filtering: The columns in the table are provided with filters enabling the user to search for what they want. The drop downs are provided for the columns: assignments, course, topic and current stage.

Implementation Steps
* Added the feature for filtering out tasks in the table by including the filteredtasks component in the StudentTasksHome.tsx file.
* The corresponding formatting for the same included in the StudentTasks.module.css file.

4. Error and Edge Case Handling: Comprehensive error handling and edge case handling strategies were implemented to provide informative feedback for failed requests or empty datasets.

5. Responsive and Accessible Design: The page implemented is fully responsive on all devices (desktop, tablet, mobile) and meets accessibility standards, including ARIA roles, ensuring a seamless and inclusive experience for all students, regardless of their device or abilities.

6. Testing and Validation: The testing phase of the project involves a manual testing process to ensure the student task view list functions reliably.

Implementation Steps
*Carrying out a detailed manual review of each task item to confirm they display accurate information, ensuring visual indicators match the design specifications.
*Simulating user interactions manually to verify that component links and buttons function correctly, confirming that all elements respond as expected.
*Evaluating visual feedback elements like hover and active states to ensure they align with the project's usability standards.

These steps are intended to confirm the interface's cohesive functionality and reliability by interacting with the system from an end-user perspective. This hands-on approach enables quick correction of any inconsistencies and improvements to the user experience. 
Login page for accessing the system 
[[File: Login_Page_Student_tasks_UI.jpg | 1000px ]] 
Navigate to the "Assignments" tab to view list of assignments 
[[File: New_Implementation_Assignments_Page.jpg | 1000px ]] 

 Major changes made: 

1. We have included a legend to improve clarity, allowing users to understand column meanings at a glance. This approach is more user-friendly than requiring users to hover over a small info icon, and it provides a cleaner, more streamlined interface.

2. We have split the task box into different parts making it easier for the user to view the Student Tasks Page.

3. The Table containing the list of assignments have been provided with dropdowns for ease of access.

==Database==
We prepared the database by cloning and configuring the reimplementation backend, adhering to the guidelines provided in the Backend Setup Instructions. We will be creating dummy assignment data for testing purposes.

 Sample of the Dummy data created 
[[File: Dummy_data_Student_Tasks_UI.jpg | 500px]]

==Components==
*App.tsx : The `App.tsx` file acts as the primary entry point for a React application, setting up routing, integrating various pages and components, and managing global states or contexts to enable seamless navigation and functionality across the app. We’ll be adding a protected route for "StudentTaskHome" to direct users with the STUDENT role to the `StudentTasksHome` component.

*StudentTasksBox.tsx : The StudentTaskbox.tsx file will display a sidebar component that emphasizes upcoming tasks, revisions, and team collaborations.

*StudentTaskHome.tsx : The StudentTaskHome.tsx file contains the main panel, presenting a comprehensive list of assignments with course information, topics, current stages, and other relevant details. This contains the dropdowns implemented in the main panel (table) for filtering based on the user's needs.

==Files created/modified==
* src/App.tsx (Modified) - This file was changed to point to the new implementation of the Student Tasks page.

* src/pages/StudentTasks/StudentTasksHome.tsx (New File) - This file was created to handle the content of task table in the Student Tasks page.

* src/pages/StudentTasks/StudentTaskBox.tsx (New File) - This file was created to handle the content of the yellow task box in the Student Tasks page.

* src/pages/StudentTasks/StudentTasks.module.css (New File) - This file was created to handle the styling of the tasks table.

* src/pages/StudentTasks/StudentTasksBox.module.css (New File) - This file was created to handle the styling of the yellow task box.

* src/pages/StudentTasks/testData.json (New File) - This file was created to store the dummy data for our implementation.

==Design Patterns and Principles==

Design patterns and principles are fundamental concepts that help developers create clean, scalable, and maintainable code. They guide the design of software structures and improve development efficiency, as they provide solutions to common problems and offer a vocabulary for communication within development teams.

1. Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification, allowing new functionality without altering existing code. It ensures modularity and reusability, which aligns with the goal of designing React components for different sections of the Student Task List page. The existing code was just altered by adding additional features.

2. Don't Repeat Yourself (DRY):Avoid duplicating code. When functionality or logic repeats, it's better to refactor it into reusable functions, classes, or modules. The StudentTaskHome and StudentTasksBox components have all the required code and have been refactored to make it reusable.

== Test Plan ==

1. Component Design and Structure: Design and organize React components to effectively support the Student Task List page, ensuring clarity and modularity.

Test Cases:
* Review the modular design of key components (e.g., header, task list, individual task items) for scalability and reusability.
* Check each component for proper structure and verify that all necessary information is displayed as expected.
* Confirm each component renders correctly within the overall page layout.

2. Task List Display: Implement functionality to accurately fetch and display assignments within the task list.

Test Cases:
* Confirm that the task list properly renders each fetched assignment.
* Test for infinite scrolling, if needed, to handle extensive assignment lists smoothly.
* Verify that loading indicators or placeholders appear while data is loading, ensuring user feedback during fetch operations.

3. Filter Assignments: Ensure that the task list filters assignments to show only those relevant to the current user.

Test Cases:
* Confirm the task list is correctly filtered based on the User ID, displaying only applicable assignments for the user.

== Important Links ==
* GitHub repo [https://github.com/aditikilledar/reimplementation-front-end]
* Pull Request: [https://github.com/expertiza/reimplementation-front-end/pull/66]

== Team ==
=====Mentor=====

* Chaitanya Srusti <crsrusti@ncsu.edu>

=====Members=====
* Aditi Killedar <akilled@ncsu.edu>
* Kruthi Rajeshwar <krajesh@ncsu.edu>
* Sphurthy Satish <sphurthy@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2463 Implement Front End for Student Task List

2024-10-30T01:05:48Z

Akilled:

== Expertiza ==
Expertiza is an open-source learning management system primarily developed with Ruby on Rails. It offers features such as creating tests and assignments, managing teams and courses, and, most importantly, providing a robust framework for peer reviews and group feedback. This project focuses on developing frontend components in React, with an emphasis on the Student Task list page. The aim is to build a fully operational user interface for these components using React.js and TypeScript.

== Introduction ==
The main objective of this project is to implement the front end for the Student Task list page within Expertiza.

== Project Description ==

===Objective===
This project’s goal is to redesign the front end of the current non-TypeScript Student Task List page on Expertiza by building a new user interface with React.js and TypeScript, ensuring a more type-safe development experience. The page will showcase all assignments the user is involved in, requiring data fetching to obtain the assignment list, filtering based on the user’s participation, and presenting the results in a visually engaging, user-friendly format through React components.
This is the visual framework for creating the user interface:

[[File: Flow_Chart_Student_tasks.jpg | 1000px]] 

===Development Steps===
*Review Current Interface: Conduct a detailed analysis of the existing Ruby on Rails UI to understand its layout and features.
*Setup Development Environment: Configure the environment to work with TypeScript and React.
*Design Components: Break down the UI into distinct React components, defining the props and states needed for each.
*Implement in Typescript: Develop the component logic in TypeScript, prioritizing type safety.
*Replicate Functionality: Ensure all features from the Rails application are mirrored in the React components, maintaining full functionality.
*Styling and Add Interactivity: Style components and integrate interactive elements using CSS.
*Testing: Perform individual component testing and end-to-end testing for the entire application.

== Design ==
===Current Implementation (Ruby on Rails)===

The existing interface on Expertiza, developed with Ruby on Rails, displays a student's task list with assignments, due dates, and progress indicators.

 Current Implementation of Expertiza with Ruby on Rails 
[[File:Expertiza_current_implementation.jpg | 1000px]]

===New Implementation (React JS & TypeScript)===

Our updated UI replicates the functionality of the original page, now leveraging TypeScript's reliability alongside React's dynamic rendering. We prioritized building a responsive, accessible interface that aligns with modern design principles. We have also included certain features to make it easy for the student to manage their assignments. 
 Implementation Overview 

1. Fetch and Display Data: The UI is designed with future live data integration in mind. Currently, we use structured placeholder data to mimic backend interactions.

Implementation Steps
*Defined TypeScript interfaces to model assignment data structures.
*Created mock data to simulate API responses for development.

2. React Component Design: We developed modular React components like Header, TaskList, and TaskItem to improve code reusability and maintainability.

 Legend 

We have included a legend on the right of the student task list, to improve clarity, allowing users to understand column meanings at a glance. This approach is more user-friendly than requiring users to hover over a small info icon, and it provides a cleaner, more streamlined interface.

Implementation Steps
==== StudentTasksBox component ====
*Implementation of the StudentTasksBox component - [https://github.com/aditikilledar/reimplementation-front-end/blob/student-tasks-ui-f24/src/pages/StudentTasks/StudentTasksBox.tsx] 

<syntaxhighlight>
const StudentTasksBox: React.FC<StudentTasksBoxProps> = ({ participantTasks, revisions, studentsTeamedWith }) => {
// Calculate total number of students teamed up with by iterating over each semester
let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

// Calculate the number of revisions that are still pending (i.e., due date is in the future)
const pendingRevisions = revisions.filter(revision => getDaysLeft(revision.dueDate) > 0);

const dueTasks = participantTasks.filter(task => getDaysLeft(task.stageDeadline) > 0);

// Group tasks by course
const tasksByCourse: { [key: string]: typeof participantTasks } = {};

dueTasks.forEach(task => {
const courseName = task.course;

if (!tasksByCourse[courseName]) {
tasksByCourse[courseName] = [];
}

tasksByCourse[courseName].push(task);
});

return (
<div className={styles.container}>
<h2>Task Summary</h2>
<div className={styles.infoBox}>
<h5>Due:</h5>
{Object.entries(tasksByCourse).map(([course, tasks]) => (
<div key={course}>
{course}
<ul>
{tasks.map(task => (
<li key={task.id}>
{task.assignment} - Due: {task.stageDeadline}
</li>
))}
</ul>
</div>
))}
</div>

<div className={styles.infoBox}>
<h5>Revisions:</h5>
<ul>
{revisions.map((revision, index) => (
<li key={index}>{revision.name}</li>
))}
</ul>
</div>

<div className={styles.infoBox}>
<div className={styles.teamedStudents}>
<h5>Total Students Teamed With: {totalStudents}</h5>
<ul>
{allStudents.map((student, index) => (
<li key={index}>{student}</li>
))}
</ul>
</div>
</div>
</div>
);

};
</syntaxhighlight> 

New UI for StudentTasksBox Component 

[[File: StudentTasksBox_Task Summary.jpg | 200px]]
[[File: StudentTasksBox_Revisions and Students Teamed With.jpg | 200px]] 

==== StudentTaskHome component ====
*Implementation of the StudentTaskHome component that handles the list of assignments along with filters (dropdowns). [https://github.com/aditikilledar/reimplementation-front-end/blob/student-tasks-ui-f24/src/pages/StudentTasks/StudentTaskHome.tsx] 
<syntaxhighlight>
const StudentTasksHome: React.FC = () => {
// init state and hooks
const currUserId = testData.current_user_id;
const dispatch = useDispatch();
const navigate = useNavigate();
const auth = useSelector((state: RootState) => state.authentication)

type StudentsTeamedWith = {
[semester: string]: string[];
};

// states to hold tasks
const taskRevisions = testData.revisions;
const participantTasks = testData.participantTasks;
console.log("participantTasks", participantTasks)

const [tasks, setTasks] = useState<Task[]>([]);
const dueTasks = testData.dueTasks;
const studentsTeamedWith: StudentsTeamedWith = testData.studentsTeamedWith;
const [filteredTasks, setFilteredTasks] = useState<Task[]>([]);

const [assignmentFilter, setAssignmentFilter] = useState('');
const [courseFilter, setCourseFilter] = useState('');
const [topicFilter, setTopicFilter] = useState('');
const [currentstageFilter, setCurrentStageFilter] = useState('');

function togglePublishingRights(id: number): void {
throw new Error('Function not implemented.');
}

let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

useEffect(() => {
// Map the data from participationTasks to the tasks state
const mappedTasks = participantTasks.map(task => ({
id: task.id,
assignment: task.assignment,
course: task.course,
topic: task.topic,
currentStage: task.current_stage, // Adjust to match your data's structure
reviewGrade: task.review_grade, // Can be a string or an object
badges: task.badges, // Keep as is since it can be string or boolean
stageDeadline: task.stage_deadline, // Adjust to match your data's structure
publishingRights: task.publishing_rights, // Boolean type
}));

setTasks(mappedTasks);
setFilteredTasks(mappedTasks);
}, [participantTasks]);

console.log("after use effect:", participantTasks)

useEffect(() => {
const filtered = tasks.filter((task) =>
(assignmentFilter ? task.assignment === assignmentFilter : true) &&
(courseFilter ? task.course === courseFilter : true) &&
(topicFilter ? task.topic === topicFilter : true) &&
(currentstageFilter ? task.topic == currentstageFilter : true)
);
setFilteredTasks(filtered);
}, [assignmentFilter, courseFilter, topicFilter, currentstageFilter, tasks]);
</syntaxhighlight>

New UI for StudentTaskHome Component 
[[File: StudentTaskHome.jpg | 1000px ]] 

3. Table Filtering: The columns in the table are provided with filters enabling the user to search for what they want. The drop downs are provided for the columns: assignments, course, topic and current stage.

Implementation Steps
* Added the feature for filtering out tasks in the table by including the filteredtasks component in the StudentTasksHome.tsx file.
* The corresponding formatting for the same included in the StudentTasks.module.css file.

4. Error and Edge Case Handling: Comprehensive error handling and edge case handling strategies were implemented to provide informative feedback for failed requests or empty datasets.

5. Responsive and Accessible Design: The page implemented is fully responsive on all devices (desktop, tablet, mobile) and meets accessibility standards, including ARIA roles, ensuring a seamless and inclusive experience for all students, regardless of their device or abilities.

6. Testing and Validation: The testing phase of the project involves a manual testing process to ensure the student task view list functions reliably.

Implementation Steps
*Carrying out a detailed manual review of each task item to confirm they display accurate information, ensuring visual indicators match the design specifications.
*Simulating user interactions manually to verify that component links and buttons function correctly, confirming that all elements respond as expected.
*Evaluating visual feedback elements like hover and active states to ensure they align with the project's usability standards.

These steps are intended to confirm the interface's cohesive functionality and reliability by interacting with the system from an end-user perspective. This hands-on approach enables quick correction of any inconsistencies and improvements to the user experience. 
Login page for accessing the system 
[[File: Login_Page_Student_tasks_UI.jpg | 1000px ]] 
Navigate to the "Assignments" tab to view list of assignments 
[[File: New_Implementation_Assignments_Page.jpg | 1000px ]] 

==Database==
We prepared the database by cloning and configuring the reimplementation backend, adhering to the guidelines provided in the Backend Setup Instructions. We will be creating dummy assignment data for testing purposes.

 Sample of the Dummy data created 
[[File: Dummy_data_Student_Tasks_UI.jpg | 500px]]

==Components==
*App.tsx : The `App.tsx` file acts as the primary entry point for a React application, setting up routing, integrating various pages and components, and managing global states or contexts to enable seamless navigation and functionality across the app. We’ll be adding a protected route for "StudentTaskHome" to direct users with the STUDENT role to the `StudentTasksHome` component.

*StudentTasksBox.tsx : The StudentTaskbox.tsx file will display a sidebar component that emphasizes upcoming tasks, revisions, and team collaborations.

*StudentTaskHome.tsx : The StudentTaskHome.tsx file contains the main panel, presenting a comprehensive list of assignments with course information, topics, current stages, and other relevant details. This contains the dropdowns implemented in the main panel (table) for filtering based on the user's needs.

==Files created/modified==
* src/App.tsx (Modified) - This file was changed to point to the new implementation of the Student Tasks page.

* src/pages/StudentTasks/StudentTasksHome.tsx (New File) - This file was created to handle the content of task table in the Student Tasks page.

* src/pages/StudentTasks/StudentTaskBox.tsx (New File) - This file was created to handle the content of the yellow task box in the Student Tasks page.

* src/pages/StudentTasks/StudentTasks.module.css (New File) - This file was created to handle the styling of the tasks table.

* src/pages/StudentTasks/StudentTasksBox.module.css (New File) - This file was created to handle the styling of the yellow task box.

* src/pages/StudentTasks/testData.json (New File) - This file was created to store the dummy data for our implementation.

==Design Patterns and Principles==

Design patterns and principles are fundamental concepts that help developers create clean, scalable, and maintainable code. They guide the design of software structures and improve development efficiency, as they provide solutions to common problems and offer a vocabulary for communication within development teams.

1. Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification, allowing new functionality without altering existing code. It ensures modularity and reusability, which aligns with the goal of designing React components for different sections of the Student Task List page. The existing code was just altered by adding additional features.

2. Don't Repeat Yourself (DRY):Avoid duplicating code. When functionality or logic repeats, it's better to refactor it into reusable functions, classes, or modules. The StudentTaskHome and StudentTasksBox components have all the required code and have been refactored to make it reusable.

== Test Plan ==

1. Component Design and Structure: Design and organize React components to effectively support the Student Task List page, ensuring clarity and modularity.

Test Cases:
* Review the modular design of key components (e.g., header, task list, individual task items) for scalability and reusability.
* Check each component for proper structure and verify that all necessary information is displayed as expected.
* Confirm each component renders correctly within the overall page layout.

2. Task List Display: Implement functionality to accurately fetch and display assignments within the task list.

Test Cases:
* Confirm that the task list properly renders each fetched assignment.
* Test for infinite scrolling, if needed, to handle extensive assignment lists smoothly.
* Verify that loading indicators or placeholders appear while data is loading, ensuring user feedback during fetch operations.

3. Filter Assignments: Ensure that the task list filters assignments to show only those relevant to the current user.

Test Cases:
* Confirm the task list is correctly filtered based on the User ID, displaying only applicable assignments for the user.

== Important Links ==
* GitHub repo [https://github.com/aditikilledar/reimplementation-front-end]
* Pull Request: [https://github.com/expertiza/reimplementation-front-end/pull/66]

== Team ==
=====Mentor=====

* Chaitanya Srusti <crsrusti@ncsu.edu>

=====Members=====
* Aditi Killedar <akilled@ncsu.edu>
* Kruthi Rajeshwar <krajesh@ncsu.edu>
* Sphurthy Satish <sphurthy@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2463 Implement Front End for Student Task List

2024-10-30T01:04:43Z

Akilled:

== Expertiza ==
Expertiza is an open-source learning management system primarily developed with Ruby on Rails. It offers features such as creating tests and assignments, managing teams and courses, and, most importantly, providing a robust framework for peer reviews and group feedback. This project focuses on developing frontend components in React, with an emphasis on the Student Task list page. The aim is to build a fully operational user interface for these components using React.js and TypeScript.

== Introduction ==
The main objective of this project is to implement the front end for the Student Task list page within Expertiza.

== Project Description ==

===Objective===
This project’s goal is to redesign the front end of the current non-TypeScript Student Task List page on Expertiza by building a new user interface with React.js and TypeScript, ensuring a more type-safe development experience. The page will showcase all assignments the user is involved in, requiring data fetching to obtain the assignment list, filtering based on the user’s participation, and presenting the results in a visually engaging, user-friendly format through React components.
This is the visual framework for creating the user interface:

[[File: Flow_Chart_Student_tasks.jpg | 1000px]] 

===Development Steps===
*Review Current Interface: Conduct a detailed analysis of the existing Ruby on Rails UI to understand its layout and features.
*Setup Development Environment: Configure the environment to work with TypeScript and React.
*Design Components: Break down the UI into distinct React components, defining the props and states needed for each.
*Implement in Typescript: Develop the component logic in TypeScript, prioritizing type safety.
*Replicate Functionality: Ensure all features from the Rails application are mirrored in the React components, maintaining full functionality.
*Styling and Add Interactivity: Style components and integrate interactive elements using CSS.
*Testing: Perform individual component testing and end-to-end testing for the entire application.

== Design ==
===Current Implementation (Ruby on Rails)===

The existing interface on Expertiza, developed with Ruby on Rails, displays a student's task list with assignments, due dates, and progress indicators.

 Current Implementation of Expertiza with Ruby on Rails 
[[File:Expertiza_current_implementation.jpg | 1000px]]

===New Implementation (React JS & TypeScript)===

Our updated UI replicates the functionality of the original page, now leveraging TypeScript's reliability alongside React's dynamic rendering. We prioritized building a responsive, accessible interface that aligns with modern design principles. We have also included certain features to make it easy for the student to manage their assignments. 
 Implementation Overview 

1. Fetch and Display Data: The UI is designed with future live data integration in mind. Currently, we use structured placeholder data to mimic backend interactions.

Implementation Steps
*Defined TypeScript interfaces to model assignment data structures.
*Created mock data to simulate API responses for development.

2. React Component Design: We developed modular React components like Header, TaskList, and TaskItem to improve code reusability and maintainability.

Implementation Steps
==== StudentTasksBox component ====
*Implementation of the StudentTasksBox component - [https://github.com/aditikilledar/reimplementation-front-end/blob/student-tasks-ui-f24/src/pages/StudentTasks/StudentTasksBox.tsx] 

<syntaxhighlight>
const StudentTasksBox: React.FC<StudentTasksBoxProps> = ({ participantTasks, revisions, studentsTeamedWith }) => {
// Calculate total number of students teamed up with by iterating over each semester
let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

// Calculate the number of revisions that are still pending (i.e., due date is in the future)
const pendingRevisions = revisions.filter(revision => getDaysLeft(revision.dueDate) > 0);

const dueTasks = participantTasks.filter(task => getDaysLeft(task.stageDeadline) > 0);

// Group tasks by course
const tasksByCourse: { [key: string]: typeof participantTasks } = {};

dueTasks.forEach(task => {
const courseName = task.course;

if (!tasksByCourse[courseName]) {
tasksByCourse[courseName] = [];
}

tasksByCourse[courseName].push(task);
});

return (
<div className={styles.container}>
<h2>Task Summary</h2>
<div className={styles.infoBox}>
<h5>Due:</h5>
{Object.entries(tasksByCourse).map(([course, tasks]) => (
<div key={course}>
{course}
<ul>
{tasks.map(task => (
<li key={task.id}>
{task.assignment} - Due: {task.stageDeadline}
</li>
))}
</ul>
</div>
))}
</div>

<div className={styles.infoBox}>
<h5>Revisions:</h5>
<ul>
{revisions.map((revision, index) => (
<li key={index}>{revision.name}</li>
))}
</ul>
</div>

<div className={styles.infoBox}>
<div className={styles.teamedStudents}>
<h5>Total Students Teamed With: {totalStudents}</h5>
<ul>
{allStudents.map((student, index) => (
<li key={index}>{student}</li>
))}
</ul>
</div>
</div>
</div>
);

};
</syntaxhighlight> 

New UI for StudentTasksBox Component 

[[File: StudentTasksBox_Task Summary.jpg | 200px]]
[[File: StudentTasksBox_Revisions and Students Teamed With.jpg | 200px]] 

==== StudentTaskHome component ====
*Implementation of the StudentTaskHome component that handles the list of assignments along with filters (dropdowns). [https://github.com/aditikilledar/reimplementation-front-end/blob/student-tasks-ui-f24/src/pages/StudentTasks/StudentTaskHome.tsx] 
<syntaxhighlight>
const StudentTasksHome: React.FC = () => {
// init state and hooks
const currUserId = testData.current_user_id;
const dispatch = useDispatch();
const navigate = useNavigate();
const auth = useSelector((state: RootState) => state.authentication)

type StudentsTeamedWith = {
[semester: string]: string[];
};

// states to hold tasks
const taskRevisions = testData.revisions;
const participantTasks = testData.participantTasks;
console.log("participantTasks", participantTasks)

const [tasks, setTasks] = useState<Task[]>([]);
const dueTasks = testData.dueTasks;
const studentsTeamedWith: StudentsTeamedWith = testData.studentsTeamedWith;
const [filteredTasks, setFilteredTasks] = useState<Task[]>([]);

const [assignmentFilter, setAssignmentFilter] = useState('');
const [courseFilter, setCourseFilter] = useState('');
const [topicFilter, setTopicFilter] = useState('');
const [currentstageFilter, setCurrentStageFilter] = useState('');

function togglePublishingRights(id: number): void {
throw new Error('Function not implemented.');
}

let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

useEffect(() => {
// Map the data from participationTasks to the tasks state
const mappedTasks = participantTasks.map(task => ({
id: task.id,
assignment: task.assignment,
course: task.course,
topic: task.topic,
currentStage: task.current_stage, // Adjust to match your data's structure
reviewGrade: task.review_grade, // Can be a string or an object
badges: task.badges, // Keep as is since it can be string or boolean
stageDeadline: task.stage_deadline, // Adjust to match your data's structure
publishingRights: task.publishing_rights, // Boolean type
}));

setTasks(mappedTasks);
setFilteredTasks(mappedTasks);
}, [participantTasks]);

console.log("after use effect:", participantTasks)

useEffect(() => {
const filtered = tasks.filter((task) =>
(assignmentFilter ? task.assignment === assignmentFilter : true) &&
(courseFilter ? task.course === courseFilter : true) &&
(topicFilter ? task.topic === topicFilter : true) &&
(currentstageFilter ? task.topic == currentstageFilter : true)
);
setFilteredTasks(filtered);
}, [assignmentFilter, courseFilter, topicFilter, currentstageFilter, tasks]);
</syntaxhighlight>

New UI for StudentTaskHome Component 
[[File: StudentTaskHome.jpg | 1000px ]] 

3. Table Filtering: The columns in the table are provided with filters enabling the user to search for what they want. The drop downs are provided for the columns: assignments, course, topic and current stage.

Implementation Steps
* Added the feature for filtering out tasks in the table by including the filteredtasks component in the StudentTasksHome.tsx file.
* The corresponding formatting for the same included in the StudentTasks.module.css file.

4. Error and Edge Case Handling: Comprehensive error handling and edge case handling strategies were implemented to provide informative feedback for failed requests or empty datasets.

5. Responsive and Accessible Design: The page implemented is fully responsive on all devices (desktop, tablet, mobile) and meets accessibility standards, including ARIA roles, ensuring a seamless and inclusive experience for all students, regardless of their device or abilities.

6. Testing and Validation: The testing phase of the project involves a manual testing process to ensure the student task view list functions reliably.

Implementation Steps
*Carrying out a detailed manual review of each task item to confirm they display accurate information, ensuring visual indicators match the design specifications.
*Simulating user interactions manually to verify that component links and buttons function correctly, confirming that all elements respond as expected.
*Evaluating visual feedback elements like hover and active states to ensure they align with the project's usability standards.

These steps are intended to confirm the interface's cohesive functionality and reliability by interacting with the system from an end-user perspective. This hands-on approach enables quick correction of any inconsistencies and improvements to the user experience. 
Login page for accessing the system 
[[File: Login_Page_Student_tasks_UI.jpg | 1000px ]] 
Navigate to the "Assignments" tab to view list of assignments 
[[File: New_Implementation_Assignments_Page.jpg | 1000px ]] 

 Legend

We have included a legend on the right of the student task list, to improve clarity, allowing users to understand column meanings at a glance. This approach is more user-friendly than requiring users to hover over a small info icon, and it provides a cleaner, more streamlined interface.

==Database==
We prepared the database by cloning and configuring the reimplementation backend, adhering to the guidelines provided in the Backend Setup Instructions. We will be creating dummy assignment data for testing purposes.

 Sample of the Dummy data created 
[[File: Dummy_data_Student_Tasks_UI.jpg | 500px]]

==Components==
*App.tsx : The `App.tsx` file acts as the primary entry point for a React application, setting up routing, integrating various pages and components, and managing global states or contexts to enable seamless navigation and functionality across the app. We’ll be adding a protected route for "StudentTaskHome" to direct users with the STUDENT role to the `StudentTasksHome` component.

*StudentTasksBox.tsx : The StudentTaskbox.tsx file will display a sidebar component that emphasizes upcoming tasks, revisions, and team collaborations.

*StudentTaskHome.tsx : The StudentTaskHome.tsx file contains the main panel, presenting a comprehensive list of assignments with course information, topics, current stages, and other relevant details. This contains the dropdowns implemented in the main panel (table) for filtering based on the user's needs.

==Files created/modified==
* src/App.tsx (Modified) - This file was changed to point to the new implementation of the Student Tasks page.

* src/pages/StudentTasks/StudentTasksHome.tsx (New File) - This file was created to handle the content of task table in the Student Tasks page.

* src/pages/StudentTasks/StudentTaskBox.tsx (New File) - This file was created to handle the content of the yellow task box in the Student Tasks page.

* src/pages/StudentTasks/StudentTasks.module.css (New File) - This file was created to handle the styling of the tasks table.

* src/pages/StudentTasks/StudentTasksBox.module.css (New File) - This file was created to handle the styling of the yellow task box.

* src/pages/StudentTasks/testData.json (New File) - This file was created to store the dummy data for our implementation.

==Design Patterns and Principles==

Design patterns and principles are fundamental concepts that help developers create clean, scalable, and maintainable code. They guide the design of software structures and improve development efficiency, as they provide solutions to common problems and offer a vocabulary for communication within development teams.

1. Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification, allowing new functionality without altering existing code. It ensures modularity and reusability, which aligns with the goal of designing React components for different sections of the Student Task List page. The existing code was just altered by adding additional features.

2. Don't Repeat Yourself (DRY):Avoid duplicating code. When functionality or logic repeats, it's better to refactor it into reusable functions, classes, or modules. The StudentTaskHome and StudentTasksBox components have all the required code and have been refactored to make it reusable.

== Test Plan ==

1. Component Design and Structure: Design and organize React components to effectively support the Student Task List page, ensuring clarity and modularity.

Test Cases:
* Review the modular design of key components (e.g., header, task list, individual task items) for scalability and reusability.
* Check each component for proper structure and verify that all necessary information is displayed as expected.
* Confirm each component renders correctly within the overall page layout.

2. Task List Display: Implement functionality to accurately fetch and display assignments within the task list.

Test Cases:
* Confirm that the task list properly renders each fetched assignment.
* Test for infinite scrolling, if needed, to handle extensive assignment lists smoothly.
* Verify that loading indicators or placeholders appear while data is loading, ensuring user feedback during fetch operations.

3. Filter Assignments: Ensure that the task list filters assignments to show only those relevant to the current user.

Test Cases:
* Confirm the task list is correctly filtered based on the User ID, displaying only applicable assignments for the user.

== Important Links ==
* GitHub repo [https://github.com/aditikilledar/reimplementation-front-end]
* Pull Request: [https://github.com/expertiza/reimplementation-front-end/pull/66]

== Team ==
=====Mentor=====

* Chaitanya Srusti <crsrusti@ncsu.edu>

=====Members=====
* Aditi Killedar <akilled@ncsu.edu>
* Kruthi Rajeshwar <krajesh@ncsu.edu>
* Sphurthy Satish <sphurthy@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2463 Implement Front End for Student Task List

2024-10-29T01:55:49Z

Akilled: /* Current Implementation in Expertiza (Ruby on Rails) */

== Expertiza ==
Expertiza is an open-source learning management system primarily developed with Ruby on Rails. It offers features such as creating tests and assignments, managing teams and courses, and, most importantly, providing a robust framework for peer reviews and group feedback. This project focuses on developing frontend components in React, with an emphasis on the Student Task list page. The aim is to build a fully operational user interface for these components using React.js and TypeScript.

== Introduction ==
The main objective of this project is to implement the front end for the Student Task list page within Expertiza.

== Project Description ==

===Objective===
This project’s goal is to redesign the front end of the current non-TypeScript Student Task List page on Expertiza by building a new user interface with React.js and TypeScript, ensuring a more type-safe development experience. The page will showcase all assignments the user is involved in, requiring data fetching to obtain the assignment list, filtering based on the user’s participation, and presenting the results in a visually engaging, user-friendly format through React components.
This is the visual framework for creating the user interface:

[[ | 1000px]] 

===Development Steps===
*Review Current Interface: Conduct a detailed analysis of the existing Ruby on Rails UI to understand its layout and features.
*Setup Development Environment: Configure the environment to work with TypeScript and React.
*Design Components: Break down the UI into distinct React components, defining the props and states needed for each.
*Implement in Typescript: Develop the component logic in TypeScript, prioritizing type safety.
*Replicate Functionality: Ensure all features from the Rails application are mirrored in the React components, maintaining full functionality.
*Styling and Add Interactivity: Style components and integrate interactive elements using CSS.
*Testing: Perform individual component testing and end-to-end testing for the entire application.

== Design ==
===Current Implementation in Expertiza (Ruby on Rails)===

The existing interface on Expertiza, developed with Ruby on Rails, displays a student's task list with assignments, due dates, and progress indicators.

TODO: insert old implementation screenshot here.

===New Implementation (React JS & TypeScript)===

Our updated UI replicates the functionality of the original page, now leveraging TypeScript's reliability alongside React's dynamic rendering. We prioritized building a responsive, accessible interface that aligns with modern design principles. We have also included certain features to make it easy for the student to manage their assignments.
 Implementation Overview 

1. Fetch and Display Data: The UI is designed with future live data integration in mind. Currently, we use structured placeholder data to mimic backend interactions.

Implementation Steps
*Defined TypeScript interfaces to model assignment data structures.
*Created mock data to simulate API responses for development.

2. React Component Design: We developed modular React components like Header, TaskList, and TaskItem to improve code reusability and maintainability.

Implementation Steps
==== StudentTasksBox component ====
*Definition of StudentTasksBox component with TypeScript props for type checking. - [ENTER LINK FOR THE LATEST COMMIT OF THE STUDENTTASKSBOX] 

<syntaxhighlight>
const StudentTasksBox: React.FC<StudentTasksBoxProps> = ({ participantTasks, revisions, studentsTeamedWith }) => {
// Calculate total number of students teamed up with by iterating over each semester
let totalStudents = 0;
let allStudents: string[] = [];
for (const semester in studentsTeamedWith) {
// Add the number of students in each semester to the total count
totalStudents += studentsTeamedWith[semester].length;
allStudents = allStudents.concat(studentsTeamedWith[semester]);
}

// Calculate the number of revisions that are still pending (i.e., due date is in the future)
const pendingRevisions = revisions.filter(revision => getDaysLeft(revision.dueDate) > 0);

const dueTasks = participantTasks.filter(task => getDaysLeft(task.stageDeadline) > 0);

// Group tasks by course
const tasksByCourse: { [key: string]: typeof participantTasks } = {};

dueTasks.forEach(task => {
const courseName = task.course;

if (!tasksByCourse[courseName]) {
tasksByCourse[courseName] = [];
}

tasksByCourse[courseName].push(task);
});

return (
<div className={styles.container}>
<h2>Task Summary</h2>
<div className={styles.infoBox}>
<h5>Due:</h5>
{Object.entries(tasksByCourse).map(([course, tasks]) => (
<div key={course}>
{course}
<ul>
{tasks.map(task => (
<li key={task.id}>
{task.assignment} - Due: {task.stageDeadline}
</li>
))}
</ul>
</div>
))}
</div>

<div className={styles.infoBox}>
<h5>Revisions:</h5>
<ul>
{revisions.map((revision, index) => (
<li key={index}>{revision.name}</li>
))}
</ul>
</div>

<div className={styles.infoBox}>
<div className={styles.teamedStudents}>
<h5>Total Students Teamed With: {totalStudents}</h5>
<ul>
{allStudents.map((student, index) => (
<li key={index}>{student}</li>
))}
</ul>
</div>
</div>
</div>
);

};
</syntaxhighlight> 

New UI for StudentTasksBox Component 

[[ | 500px]] 

==== StudentTasksHome component ====
*Creation of stateful StudentTasksHome component that handles list of assignments. [ENTER LINK FOR THE LATEST COMMIT OF THE STUDENTTASKSHOME] 
<syntaxhighlight>
const StudentTasks: React.FC = () => {
// State and hooks initialization
const participantTasks = testData.participantTasks;
const currentUserId = testData.current_user_id;
const auth = useSelector((state: RootState) => state.authentication);
const dispatch = useDispatch();
const navigate = useNavigate();

// State to hold tasks
const [tasks, setTasks] = useState<Task[]>([]);
const exampleDuties = testData.dueTasks;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Effect to process tasks on component mount or update
useEffect(() => {
if (participantTasks) {
const filteredParticipantTasks = participantTasks.filter(task => task.participant_id === currentUserId);

const mergedTasks = filteredParticipantTasks.map(task => {
return {
id: task.id,
assignment: task.assignment,
course: task.course,
topic: task.topic || '-',
currentStage: task.current_stage || 'Pending',
reviewGrade: task.review_grade || 'N/A',
badges: task.badges || '',
stageDeadline: task.stage_deadline || 'No deadline',
publishingRights: task.publishing_rights || false
};
});
setTasks(mergedTasks);
}
}, [participantTasks]);
</syntaxhighlight>

New UI for StudentTasks Component 
[[]] 

3. Table Filtering: The columns in the table are provided with filters enabling the user to search for what they want. The drop downs are provided for the columns: assignments, course, topic and current stage.

Implementation Steps
* Added the feature for filtering out tasks in the table by including the filteredtasks component in the StudentTasksHome.tsx file.
* The corresponding formatting for the same included in the StudentTasks.module.css file.

4. Error and Edge Case Handling: Comprehensive error handling and edge case handling strategies were implemented to provide informative feedback for failed requests or empty datasets.

5. Testing and Validation: The testing phase of the project involves a manual testing process to ensure the student task view list functions reliably.

Implementation Steps
* Perfoming Integrations tests to see if the iimplemented UI is able to interact with the live data which is currently in Expertiza database.
*Carrying out a detailed manual review of each task item to confirm they display accurate information, ensuring visual indicators match the design specifications.
*Simulating user interactions manually to verify that component links and buttons function correctly, confirming that all elements respond as expected.
*Evaluating visual feedback elements like hover and active states to ensure they align with the project's usability standards.

These steps are intended to confirm the interface's cohesive functionality and reliability by interacting with the system from an end-user perspective. This hands-on approach enables quick correction of any inconsistencies and improvements to the user experience. 
                                                                                                                                                        Login page for accessing the system
                                                        
                                             [[]]
                                                                                                                                    Navigate to the "Assignments" tab to view list of assignments
                                                        
                                             [[]] 

==Database==
We prepared the database by cloning and configuring the reimplementation backend, adhering to the guidelines provided in the Backend Setup Instructions. We will be creating dummy assignment data for testing purposes.

==Components==
*App.tsx : The `App.tsx` file acts as the primary entry point for a React application, setting up routing, integrating various pages and components, and managing global states or contexts to enable seamless navigation and functionality across the app. We’ll be adding a protected route for "StudentTaskHome" to direct users with the STUDENT role to the `StudentTasksHome` component.

*StudentTasksBox.tsx : The StudentTaskbox.tsx file will display a sidebar component that emphasizes upcoming tasks, revisions, and team collaborations.

*StudentTasksHome.tsx : The StudentTasksHome.tsx file contains the main panel, presenting a comprehensive list of assignments with course information, topics, current stages, and other relevant details. This contains the dropdowns implemented in the main panel (table) for filtering based on the user's needs.

==Files created/modified==
* src/App.tsx

* src/pages/StudentTasks/StudentTasksHome.tsx (New File)

* src/pages/StudentTasks/StudentTaskBox.tsx (New File)

* src/pages/StudentTasks/StudentTasks.module.css (New File)

* src/pages/StudentTasks/StudentTasksBox.module.css (New File)

* src/pages/StudentTasks/testData.json (New File)

==Design Patterns and Principles==

Design patterns and principles are fundamental concepts that help developers create clean, scalable, and maintainable code. They guide the design of software structures and improve development efficiency, as they provide solutions to common problems and offer a vocabulary for communication within development teams.

1. Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification, allowing new functionality without altering existing code. It ensures modularity and reusability, which aligns with the goal of designing React components for different sections of the Student Task List page. The existing code was just altered by adding additional features.

2. Don't Repeat Yourself (DRY):Avoid duplicating code. When functionality or logic repeats, it's better to refactor it into reusable functions, classes, or modules. The StudentTaskHome and StudentTasksBox components have all the required code and have been refactored to make it reusable.

== Test Plan ==

1. Component Design and Structure: Design and organize React components to effectively support the Student Task List page, ensuring clarity and modularity.

Test Cases:
* Review the modular design of key components (e.g., header, task list, individual task items) for scalability and reusability.
* Check each component for proper structure and verify that all necessary information is displayed as expected.
* Confirm each component renders correctly within the overall page layout.

2. Task List Display: Implement functionality to accurately fetch and display assignments within the task list.

Test Cases:
* Confirm that the task list properly renders each fetched assignment.
* Test for pagination or infinite scrolling, if needed, to handle extensive assignment lists smoothly.
* Verify that loading indicators or placeholders appear while data is loading, ensuring user feedback during fetch operations.

3. Filter Assignments: Ensure that the task list filters assignments to show only those relevant to the current user.

Test Cases:
* Confirm the task list is correctly filtered based on the User ID, displaying only applicable assignments for the user.

== Important Links ==
* GitHub repo [https://github.com/aditikilledar/reimplementation-front-end]
* Forked From: [https://github.com/expertiza/reimplementation-front-end]
* Demo video: []

== Team ==
=====Mentor=====

* Chaitanya Srusti <crsrusti@ncsu.edu>

=====Members=====
* Aditi Killedar <akilled@ncsu.edu>
* Kruthi Rajeshwar <krajesh@ncsu.edu>
* Sphurthy Satish <sphurthy@ncsu.edu>