CSC/ECE 517 Fall 2024 - E2484. Reimplement participants controller.rb
About Expertiza
Expertiza is an open source project based on Ruby on Rails framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.
Introduction
This project aims to reimplement the participants_controller.rb and participants_helper.rb in the new Expertiza system. The participants_controller.rb manages participants within assignments, and this reimplementation focuses on streamlining its methods, eliminating redundancy, and enhancing code readability and maintainability.
Requirements
participants_controller.rb Methods: Fully implement each controller method with the same functionality as the current controller. participants_helper.rb : Integrate relevant helper methods to streamline functionality and remove redundancy. Existing Issues
Reimplement participants_controller.rb while addressing the following:
Design / Proposed Solution
Controller Diagram
participants_controller.rb Methods / API Calls
| # | Method | Endpoint | Description |
|---|---|---|---|
| 1 | index | GET /participants
|
Return a list of participants |
| 2 | show | GET /participants/:id
|
Return a specified participant |
| 3 | create | POST /participants
|
Create a participant |
| 4 | update_permissions | PATCH /participants/:id/permissions
|
Update the permissions of a participant |
| 5 | update_handle | PATCH /participants/:id/handle
|
Update the handle of a participant |
| 6 | destroy | DELETE /participants/:id
|
Delete a specified participant |
| 7 | participant_params | - | Permitted parameters for creating or updating a Participant object |
The following methods were removed from participants_controller.rb :
action_allowed? - No impact on functionality controller_locale - No impact on functionality inherit - Since there is no direct relationship between the Participant and Course classes, this logic is redundant and no longer necessary bequeath_all - Since there is no direct relationship between the Participant and Course classes, this logic is redundant and no longer necessary delete - Handled in the remove_participant method of the AssignmentsController ( assignments_controller.rb ) view_copyright_grants - Incorrectly implemented in the old implementation get_user_info - All needed user data can be accessed by leveraging the Participant model's belongs_to relationship to the User model get_signup_topics_for_assignment - Handled in the index method of the SignUpTopicsController ( sign_up_topics_controller.rb ) participants_helper.rb Methods
The methods in participants_helper.rb are outdated and do not impact any functionality in participants_controller.rb.
As a result, these methods will not be carried forward to the new implementation:
upload_users - Logic for creating a User specifically for the Assignment and Course classes. Since there is no direct relationship between the User and these classes, this logic is redundant and no longer necessary define_attributes - Same reason as above define_user - Same reason as above create_new_user - Same reason as above add_user_to_assignment - Same reason as above. Furthermore, since the Participant and Assignment classes are directly related, this functionality has been replaced by the add_participant method in AssignmentsController (assignments_controller.rb) add_user_to_course - Same reason as above get_config - Same reason as above store_item - Same reason as above participant_permissions - Outdated way of updating permissions, handled more effectively by the update_permissions method in ParticipantsController (participants_controller.rb) Pattern(s)
Facade: "A simplified interface that performs many other actions behind the scenes."
The participants_controller.rb uses the Facade Design Pattern to streamline interactions with the Expertiza backend, abstracting away complex logic and data handling tasks into a simplified API layer. A lot of calls to various services, objects, and features are abstracted, providing a unified, cohesive interface. By centralizing these calls, the controller can reduce dependencies on specific backend structures, making it easier for the front end to perform actions with minimal knowledge of what is going on in the backend, enhancing the maintainability and scalability of our codebase. Some such examples would be to call all the participants of a specific assignment, or pulling information about the course from a participant. Things that would otherwise complicate the front end due to the need to hunt through the backend for information that they need can be abstracted away into the facade interface. The current implementation already employs the facade pattern by its nature, but we will improve it by specifically targeting features of the facade design pattern.
SOLID Principle(s)
Open and Closed Principle: "Software entities should be open for extension, but closed for modification."
Currently, the code directly checks the type of curr_object to determine whether it’s an Assignment or Course, which can make it challenging to extend or modify. To address this, we will implement polymorphism by moving participant-related logic into the respective classes (Assignment, Course, etc.). Each class will define its own behavior for handling participants by overriding a common interface or inheriting from a shared base class. For example, A ParticipantHelper file will define methods like add_user_to_course/assignment, store item, participant_permissions, and numerous other non-idiomatic methods that go against the model view controller design pattern. Method operations that implement business logic, such as the methods listed before, should generally not be the responsibility of the controller.
Single Responsibility Principle: "A class should only have one responsibility and should never have more than one reason to change."
The current implementation of the participant controller mostly aligns with the Single Responsibility Principle, but some methods have more than one responsibility, such as combining backend logic with UI feedback. Many methods within the ParticipantsController class have this type of combined logic, for example, list, add, and inherit methods. These methods blend participant management logic with flash message handling. To make our code comply with the Single Responsibility Principle, we can move these flash messages into a helper method. These modifications reduce the controller’s responsibilities, improving our code’s readability and reusability. Lastly, the frontend developers will have predictable API behavior and consistent responses when our code adheres to the Single Responsibility Principle.
Implementation
Implement participants_controller.rb Methods
Refer to the participants_controller.rb Methods / API Calls section for all design-related inquiries
| Old Method Name | Action | New Method Name |
|---|---|---|
| action_allowed? | Removed | - |
| controller_locale | Removed | - |
| list | Renamed | index |
| add | Renamed | create |
| update_authorizations | Renamed | update_permissions |
| destroy | No Change | destroy |
| inherit | Removed | - |
| bequeath_all | Removed | - |
| change_handle | Renamed | update_handle |
| delete | Removed | - |
| view_copyright_grants | Removed | - |
| participant_params | No Change | participant_params |
| get_user_info | Removed | - |
| get_signup_topics_for_assignment | Removed | - |
| - | Added | show |
To be expanded upon during implementation
Import from participants_helper.rb
Refer to the participants_helper.rb Methods section for all design-related inquiries
| Old Method Name | Action | New Method Name |
|---|---|---|
| upload_users | Removed | - |
| define_attributes | Removed | - |
| define_user | Removed | - |
| create_new_user | Removed | - |
| add_user_to_assignment | Removed | - |
| add_user_to_course | Removed | - |
| get_config | Removed | - |
| store_item | Removed | - |
| participant_permissions | Removed | - |
API Creation
Refer to the participants_controller.rb Methods / API Calls section for all design-related inquiries
To be expanded upon during implementation
Testing with rswag
Refer to the Testing Plan section
To be expanded upon during implementation
Swagger UI Video Documentation
To be added at a later time
Testing Plan
rswag
We will use rswag to test and document our project’s API endpoints. Rswag integrates RSpec testing with Swagger, allowing us to define test cases in RSpec to validate functionality while automatically generating interactive Swagger documentation. This documentation, accessible through Swagger UI, provides developers and stakeholders with a user-friendly way to explore and interact with our API endpoints.
Tests
| Test ID | Test Description |
|---|---|
| 1 | Test 'index' with valid model (Assignment) and ID - Should list participants |
| 2 | Test 'index' with invalid model (Assignment) and ID - Should return an error message |
| 3 | Test 'index' when there are no participants - Should return an empty list |
| 4 | Test 'show' with valid participant ID - Should return the specified participant details |
| 5 | Test 'show' with invalid participant ID - Should return participant not found |
| 6 | Test 'create' with valid user detail - Should successfully create a new participant |
| 7 | Test 'create' with duplicate user information - Should return an error message indicating that the participant already exists |
| 8 | Test 'create' with invalid data format - Should return a validation error |
| 9 | Test 'update_permissions' with valid participant ID and permissions - Should update participant’s permissions successfully |
| 10 | Test 'update_permissions' with valid participant ID and invalid permissions - Should return a validation error |
| 11 | Test `update_permissions` with invalid participant ID - Should return participant not found message |
| 12 | Test 'update_handle' with valid participant ID and unique handle - Should successfully update |
| 13 | Test 'update_handle' with duplicate handle - Should return an error message indicating handle is in use |
| 14 | Test 'update_handle' with invalid participant ID - Should return participant not found message |
| 15 | Test 'destroy' with valid participant ID - Should delete the specified participant |
| 16 | Test 'destroy' with invalid participant ID - Should return participant not found message |
| 17 | Test 'destroy for participant who has associated records - Should return an error message or handle the cascading deletions |
| 18 | Test 'participant_params' with all required parameters - Should proceed with the action |
| 19 | Test 'participant_params' with missing required parameters - Should return an error message |
Team
Mentor
- Jay Patel <jhpatel9@ncsu.edu>
Students
- Pierce Whelan <pwwhelan@ncsu.edu>
- Calvin Jiang <crjiang@ncsu.edu>
- Hechun Zhang <hzhang56@ncsu.edu>
Relevant Links
Pull Request [1]
GitHub Repository [2]
GitHub Project Board [3]
participants_controller.rb in Old Expertiza [4]
participants_helper.rb in Old Expertiza [5]