CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses

Expertiza

Expertiza is an open-source learning management system developed with Ruby on Rails, aimed at enhancing collaborative learning through peer review and teamwork. It enables educators to create assignments in various formats, supports peer assessments, and allows students to work individually or in teams. Designed to foster critical thinking and interactive learning, Expertiza provides educators with tools to monitor progress and facilitate feedback, making it a valuable platform for managing assignments and promoting collaborative education.

Introduction

The “UI and Backend for Courses” project aims to improve course management in Expertiza by developing a user-friendly interface with React and TypeScript and implementing robust backend CRUD operations. The backend supports role-based access control, allowing Admins and Instructors to perform course-related actions according to their permissions, ensuring secure and efficient course management.

Problem Statement

The primary goal of this project is to create an efficient and user-friendly system for managing courses within Expertiza, with a strong emphasis on backend role-based permissions. The system should allow different user roles—Admin and Instructors to interact with course data in ways appropriate to their responsibilities. Admins and Instructors require full access to create, read, update, and delete courses, enabling them to manage course information comprehensively. This role-based control ensures that only authorized users can make significant changes, enhancing both security and data integrity within the course management system.

Design Goals

1. Role-Based CRUD Operations: Implement precise role-based access control, allowing Admins and Instructors full CRUD permissions on courses, while restricting TAs to read and update access only. This ensures data integrity and security by controlling access based on user roles.
2. Efficient Data Handling: Design CRUD operations to handle large datasets efficiently, optimizing database queries to support quick data retrieval and updates, which is essential for managing potentially extensive course information.
3. Error Handling and Validation: Ensure robust error handling and input validation on all endpoints to prevent invalid data from entering the system and to provide clear error responses, improving system reliability and user feedback.
4. API Documentation and Testing: Use RSwag to document and test each CRUD endpoint, generating interactive Swagger documentation to streamline development, ease future integrations, and facilitate testing of all course-related operations.
5. Modular and Scalable Architecture: Structure the backend with modular components and adhere to design principles (e.g., SRP, DRY) to make the system maintainable and scalable, allowing for future extensions with minimal code duplication and impact on existing functionality.

Implementation Plan

The implementation plan focuses on enhancing the course management system by integrating role-based access control and robust CRUD operations. The backend, developed using Ruby on Rails, enforces strict permissions, allowing Admins and Instructors full control over courses while restricting TAs to read and update actions. The UI, developed using React and TypeScript, provides a user-friendly interface for managing courses, assigning/removing TAs, and duplicating courses. Centralized permission logic ensures security, while adherence to design principles like SRP and DRY enhances maintainability. Comprehensive testing with RSpec, Postman, and Swagger ensures system reliability, and API documentation simplifies usage and future integrations.

Pros of the Implementation Plan

• Security: Role-based access control ensures only authorized actions are allowed.
• Maintainability: Centralized logic and modular design simplify updates and debugging.
• Scalability: Modular architecture supports easy addition of new features or roles.
• Performance: Optimized database queries ensure efficient data retrieval and updates.
• User-Friendly: React-based UI enhances usability and ensures a seamless experience.
• Error Resilience: Robust error handling provides clear feedback and maintains stability.
• Testing Assurance: Comprehensive automated and manual testing ensures reliability.
• Future-Proofing: Adherence to best practices enables easy extension without impacting existing functionality.

Fig 5.1.1 Class Diagram for Course Management.

Fig 5.1.2 Sequence Diagram for Course Management.

Implementation

UI Enhancements

Pre-population of Course Data and Update Button Toggle

Fig 5.1.3: Pre-population of Course and Update Button Toggle.

As show in the above screenshot, To streamline the course editing process, all the fields such as course Name, course directory, course information etc.are now pre-populated from the database. This reduces redundant inputs, enhances efficiency, and minimizes errors. The update button functionality has been enhanced to dynamically toggle between active and disabled states based on form validation to check if there is any change in the data.

Action Icons

Fig 5.1.4: Action icons for all courses.

As shown in the above image, The action icons, such as edit, delete, assign, and copy, are sourced from the official design guidelines for the Expertiza project. These icons ensure visual consistency and align with the established UI/UX standards, providing a familiar and intuitive interface for users.

"Add Course" Authorization

Fig 5.1.5: Comparison of Add course feature for Admin and Instructor.

As shown in the above image, In the Admin View, the "Add Course" button allows administrators to assign courses to any instructor, providing full control over course assignments across the system. Conversely, in the Instructor View, the "Add Course" functionality is restricted, with the instructor dropdown grayed out, limiting instructors to assigning courses only to themselves. This distinction ensures that administrators retain broader management capabilities, while instructors focus solely on their own course assignments.

Reimplemented Methods

In this project, we have reimplemented few existing methods and functions from the previous version, focusing on enhancing code readability, optimization, and adherence to coding best practices. While the core functionality of these methods remains unchanged, we refactored the code to improve its maintainability and efficiency. This reimplementation allows for a cleaner structure, making the codebase easier to understand, debug, and extend in the future. By following best practices, we ensured that the code is both modular and scalable, paving the way for future development without compromising performance or functionality.

"handleCourseSuccess and handleCourseError" methods Commit

Fig 5.1: Comparison of original and re-implemented handleCourseSuccess and handleCourseError method

In the reimplemented version of code in CourseEditor.tsx file, the handleCourseSuccess and handleCourseError functions have been separated to enhance readability and follow the Single Responsibility Principle. The handleCourseSuccess function manages success responses, triggering an alert and navigating to the courses page if the course operation is successful. The handleCourseError function handles errors by displaying an alert if any issue occurs. Two useEffect hooks individually call these functions, ensuring that success and error handling are decoupled and each function addresses a specific task, aligning with SRP.

"handleDeleteSuccess" method Commit

Fig 5.2: Comparison of original and re-implemented handleDeleteSuccess method

In the previous code, the success handling code is directly tied to displaying an alert and closing the modal, limiting flexibility. so we added a new method handleDeleteSuccess which does the success handling logic. we made this component more flexible. Now, if we need to substitute the success behavior (for instance, to log the deletion or trigger another action), we can simply modify or replace handleDeleteSuccess without changing the core logic of the component. This adheres to Liskov Substitution Principle by allowing the component’s success handling to be easily extended or substituted while preserving its functionality.

New and Enhanced Methods

In this project, we implemented new methods and enhanced existing functionalities within the CoursesController. These changes focus on improving security, ensuring better role-based access control, and adding meaningful logging for debugging purposes. By introducing these new methods and modifications, we ensured that the controller adheres to best practices, is more robust, and facilitates smooth interactions between users and the API.

authorize_manage_courses Method Commit

Purpose: This new method introduces strict role-based access control to sensitive actions like create and destroy. It ensures that only users with appropriate permissions (Admins and Instructors) can perform these operations, preventing unauthorized access to critical functionalities.

Implementation:

# Restricts actions like adding or deleting courses to Admins and Instructors
def authorize_manage_courses
  unless Permissions.can_manage_courses?(current_user)
    render json: { error: 'Unauthorized action' }, status: :forbidden
  end
end

Enhancements:
• Role-Based Control: Ensures that only users with sufficient privileges (defined in the Permissions module) can create or delete courses.
• Security: Protects the application from unauthorized actions by validating user roles.
• Error Handling: Returns a 403 Forbidden status with a clear error message for unauthorized attempts.

Impact: This method aligns with the Role-Based Access Control (RBAC) design principle, enhancing the system’s security and ensuring that actions are performed only by authorized users.

Debug Logging in index and show Actions Commit

Purpose: Enhancements were made to the index and show actions by adding meaningful debug logs. These logs provide better insights into the flow of execution, which is particularly useful during development and debugging.

Implementation:

# List all the courses
def index
  puts "IN INDEX"
  puts current_user.full_name
  courses = Course.all
  render json: courses, status: :ok
end

# Get a course
def show
  puts "In Show"
  render json: @course, status: :ok
end

Enhancements:
• Debug Logging: Outputs the current user’s name and context-specific messages to the logs.
• Transparency: Helps developers trace the flow of execution and understand user interactions with the API.

Impact: While the core functionality remains unchanged, the added logs improve maintainability and make debugging easier for developers, contributing to a more transparent and traceable codebase.

Enhanced authorize_manage_courses Method Commit

Commit Description:
We refined the authorize_manage_courses method to enforce strict role-based access control for critical operations like create, update, delete, and copy courses. This ensures that only authorized roles (Admins, Instructors, and Super Administrators) can manage courses, improving security and compliance.

Key Changes:
• Added detailed error messages for unauthorized actions to improve user guidance.
• Centralized role-based access checks using the Permissions module for consistency across actions.

Updated Method:

def authorize_manage_courses
  unless Permissions.can_manage_courses?(current_user)
    render json: { error: 'You do not have sufficient privileges for this action. Please contact the course instructor or admin.' }, status: :forbidden
  end
end

Impact:
• Prevents unauthorized users from performing critical actions.
• Aligns with the Single Responsibility Principle (SRP) by delegating role checks to a dedicated module.

Improved destroy Action Commit

Commit Description: The destroy method was updated to include a more descriptive success message that displays the course name. This enhances clarity and provides better feedback to users after deleting a course.

Updated Method:

def destroy
  @course.destroy
  render json: { message: "Course #{@course.name} has been successfully deleted." }, status: :no_content
end

Impact: Improves user experience by offering precise feedback on completed actions.

Centralized Permission Logic in Permissions Module Commit

Commit Description: The Permissions module was enhanced to act as a single source of truth for managing role-based access. This ensures consistent permission checks across the application.

Updated Method:

def self.can_manage_courses?(user)
  user.role.super_administrator? || user.role.administrator? || user.role.instructor?
end

Impact:
• Ensures DRY (Don’t Repeat Yourself) compliance by centralizing access logic.
• Simplifies future updates to permission rules without needing to modify multiple controllers.

Refactored index and show Actions Commit

Commit Description: The index and show methods were updated to include clearer log messages for better debugging and transparency.

Updated Methods:

def index
  puts "IN INDEX"
  puts current_user.full_name
  courses = Course.all
  render json: courses, status: :ok
end

def show
  puts "In Show"
  render json: @course, status: :ok
end

Impact:
• Enhances developer experience by providing insights during debugging.
• No changes to core functionality ensure backward compatibility.

Design Principles

Single Responsibility Principle (SRP)

• Definition: A class or function should have only one reason to change, meaning it should focus on a single task or responsibility.
• Implementation in the Project: Each function in the course management module (e.g., create, update, delete, and read functions) is designed to handle only one specific action related to course management. For example, the create function is solely responsible for handling the addition of new courses, while update handles modifications to existing courses. By isolating these responsibilities, changes in one function (e.g., adding new validations to create) don’t impact others. This separation allows for easier testing, debugging, and future modifications without introducing unintended side effects.

Don’t Repeat Yourself (DRY) Principle

• Definition: Redundant code should be minimized by consolidating repetitive functionality into reusable functions or modules.
• Implementation in the Project: Shared functionalities, such as data validation, error handling, and database operations, are extracted into helper modules that can be reused across different functions. For instance, if multiple actions (like create and update) require data validation, the validation logic can be placed in a helper function and invoked as needed. This approach reduces redundancy, making the code more concise, easier to maintain, and less error-prone. It also enhances scalability, as any updates to the validation logic need only be made in one place.

Encapsulation

• Definition: Data and methods should be contained within their respective classes or modules, with controlled access to prevent unintended modification or misuse.
• Implementation in the Project: Backend controllers in the project are designed to handle only essential data and expose only necessary functionality. Access to instance variables and controller actions is restricted, and sensitive operations are encapsulated within protected functions. For instance, only authorized roles (like Admin and Instructor) can access certain CRUD operations. Encapsulation also promotes data integrity by ensuring that only authorized functions can modify or interact with critical data fields, preventing unauthorized access or accidental changes.

Role-Based Access Control (RBAC)

• Definition: Access to specific functionalities should be limited based on the user’s role, enhancing security and usability.
• Implementation in the Project: In the course management system, only Admins and Instructors have full CRUD permissions, while TAs are restricted from creating and deleting courses. This role-based control is implemented on the backend to ensure secure and appropriate access, preventing unauthorized actions. By enforcing these restrictions at the code level, the system maintains data security and ensures that only users with the proper permissions can perform certain actions.

Testing Plan

We employed a comprehensive testing strategy that combines manual testing using Postman, automated testing with RSpec, and API documentation and testing through Swagger. This approach ensures the thorough validation of our Courses API’s functionality, security, and usability across various scenarios.

Manual testing with Postman

Postman was used extensively to test the API endpoints during development. Below are examples of the endpoints tested:

GET /api/v1/courses: Endpoint to retrieve all courses in the system.

Verifies proper data retrieval and handling for both empty and non-empty course datasets.

Fig 5.1.1 Postman UI displaying API testing for retrieving all courses.

POST /api/v1/courses: Endpoint to create a new course.

Example request includes course parameters like name, directory_path, and instructor_id.

Fig 5.1.2 Postman UI displaying API testing for course creation.

GET /api/v1/courses/1: Endpoint to fetch details of a specific course using its ID.

Validates the show action functionality.

Fig 5.1.3 Postman UI displaying API testing for fetching course details.

PATCH/PUT /api/v1/courses/1: Endpoint to update course details, such as changing the course name or instructor.

Tests validation and error handling for invalid updates.

Fig 5.1.4 Postman UI displaying API testing for updating a course.

DELETE /api/v1/courses/1: Endpoint to delete a course by ID.

Validates the proper functioning of the destroy action and checks for restricted access for unauthorized users.

Fig 5.1.5 Postman UI displaying API testing for deleting a course.

POST /api/v1/courses/1/copy: Endpoint to create a copy of an existing course.

Validates whether the course copy action is successful and tests edge cases for invalid requests, such as when a course does not exist.

Fig 5.1.6 Postman UI displaying API testing for copying a course.

Automated Testing with Rspec

Scenario 1: Retrieving All Courses

Validates that all courses can be retrieved successfully.

Expectation: Expects a 200 OK status and a JSON array of courses.

describe 'GET /courses' do
 it 'retrieves all courses' do
   get '/api/v1/courses'
   expect(response).to have_http_status(:ok)
   expect(JSON.parse(response.body)).to be_an(Array)
 end
end

Scenario 2: Retrieving a Single Course

Tests retrieving a course with a valid ID.

Expectation: Expects a 200 OK status and JSON details of the course.

describe 'GET /courses/:id' do
 context 'with a valid course ID' do
   it 'retrieves the course details' do
     course = create(:course)
     get "/api/v1/courses/#{course.id}"
     expect(response).to have_http_status(:ok)
     expect(JSON.parse(response.body)['id']).to eq(course.id)
   end
 end
end

Scenario 3: Creating a New Course

Validates the creation of a new course with appropriate parameters.

Expectation: Expects a 201 Created status and JSON response with the created course details.

describe 'POST /courses' do
 context 'with valid parameters' do
   it 'creates a new course' do
     valid_params = { course: attributes_for(:course) }
     expect {
       post '/api/v1/courses', params: valid_params
     }.to change(Course, :count).by(1)
     expect(response).to have_http_status(:created)
   end
 end
end

Scenario 4: Handling Invalid Course Creation

Tests course creation with invalid parameters.

Expectation: Expects a 422 Unprocessable Entity status and JSON error details.

context 'with invalid parameters' do
 it 'does not create a new course' do
   invalid_params = { course: { name:  } }
   expect {
     post '/api/v1/courses', params: invalid_params
   }.not_to change(Course, :count)
   expect(response).to have_http_status(:unprocessable_entity)
 end
end

Scenario 5: Updating an Existing Course

Validates that an existing course can be updated with valid parameters.

Expectation: Expects a 200 OK status and the updated course details in JSON.

describe 'PUT /courses/:id' do
 context 'with valid parameters' do
   it 'updates the course' do
     course = create(:course)
     valid_params = { course: { name: 'Updated Course Name' } }
     put "/api/v1/courses/#{course.id}", params: valid_params
     expect(response).to have_http_status(:ok)
     expect(course.reload.name).to eq('Updated Course Name')
   end
 end
end

Scenario 6: Deleting a Course

Tests the deletion of a course with a valid ID.

Expectation: Expects a 204 No Content status and decreases course count.

describe 'DELETE /courses/:id' do
 it 'deletes the course' do
   course = create(:course)
   expect {
     delete "/api/v1/courses/#{course.id}"
   }.to change(Course, :count).by(-1)
   expect(response).to have_http_status(:no_content)
 end
end

Scenario 7: Handling Unauthorized Actions

Ensures actions restricted to admins and instructors return proper responses for unauthorized users.

Expectation: Expects a 403 Forbidden status and an error message.

describe 'POST /courses' do
 it 'restricts access for unauthorized users' do
   allow_any_instance_of(Api::V1::CoursesController).to receive(:current_user).and_return(create(:ta))
   post '/api/v1/courses', params: { course: attributes_for(:course) }
   expect(response).to have_http_status(:forbidden)
 end
end

Scenario 8: Copying a Course

Validates the ability to create a copy of an existing course.

Expectation: Expects a 200 OK status and a success message.

describe 'POST /courses/:id/copy' do
 it 'creates a copy of the course' do
   course = create(:course)
   post "/api/v1/courses/#{course.id}/copy"
   expect(response).to have_http_status(:ok)
   expect(JSON.parse(response.body)['message']).to include("copied")
 end
end

API Documentation and Testing with Swagger

To ensure clear and interactive API documentation, we integrated Swagger into our Rails application, enabling seamless understanding and testing of all course-related API endpoints.

Setup:
1. We used the rswag gem to integrate Swagger with our Rails application.
2. The gem was configured to automatically generate Swagger documentation for all API endpoints.

Documentation:
1. Each endpoint in the Courses API is annotated with descriptions, parameter details, request bodies, and response schemas.
2. The documentation covers:
       • Role-based access control for endpoints.
       • Validation of input parameters, detailing required and optional fields.
       • Expected response statuses (e.g., 200 OK, 201 Created, 403 Forbidden, 422 Unprocessable Entity).
       • The documentation is updated dynamically, ensuring consistency with any changes made to the API.

Interactive Testing:
1. The Swagger UI provides an interactive browser-based interface to test all API endpoints.
2. Features include:
       • Automatic generation of example requests for each endpoint.
       • Ability to send test requests and view real-time responses.
       • Error responses displayed with detailed information for debugging.
       • This functionality simplifies the testing process for developers and provides a hands-on tool for non-technical stakeholders to verify API functionality.

Fig 5.3: Swagger UI displaying API documentation and interactive testing interface for Courses endpoints.

Relevant Links

Github Repository for Courses UI: https://github.com/SurajRKU/reimplementation-front-end
Github Repository for Courses Back-end: https://github.com/yuktasree/reimplementation-back-end
Pull Request for Courses UI: https://github.com/expertiza/reimplementation-front-end/pull/70
Pull Request for Courses Back-end: https://github.com/expertiza/reimplementation-back-end/pull/143
Test Video Link: https://youtu.be/N0aKESb4l5g?si=kzyEA7rlFAKn6g96

CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses

Expertiza

Introduction

Problem Statement

Design Goals

Implementation Plan

Pros of the Implementation Plan

Implementation

UI Enhancements

Pre-population of Course Data and Update Button Toggle

Action Icons

"Add Course" Authorization

Reimplemented Methods

"handleCourseSuccess and handleCourseError" methods Commit

"handleDeleteSuccess" method Commit

New and Enhanced Methods

authorize_manage_courses Method Commit

Debug Logging in index and show Actions Commit

Enhanced authorize_manage_courses Method Commit

Improved destroy Action Commit

Centralized Permission Logic in Permissions Module Commit

Refactored index and show Actions Commit

Design Principles

Single Responsibility Principle (SRP)

Don’t Repeat Yourself (DRY) Principle

Encapsulation

Role-Based Access Control (RBAC)

Testing Plan

Manual testing with Postman

Automated Testing with Rspec

Scenario 1: Retrieving All Courses

Scenario 2: Retrieving a Single Course

Scenario 3: Creating a New Course

Scenario 4: Handling Invalid Course Creation

Scenario 5: Updating an Existing Course

Scenario 6: Deleting a Course

Scenario 7: Handling Unauthorized Actions

Scenario 8: Copying a Course

API Documentation and Testing with Swagger

Relevant Links

Team

Mentor

Members

Navigation menu

Search