CSC/ECE 517 Spring 2023 - E2330. Reimplement Invitation Controller
Project Overview
Expertiza Background
Expertiza is an online platform designed to facilitate peer review and submission of various types of academic work, including articles, codes, and websites. The application allows instructors to add assignments, grade them, and assign students to teams based on their topic preferences. The platform also enables students to provide feedback on each other's work through peer reviews, which can be helpful in improving the quality of their projects. Expertiza is backed by the National Science Foundation.
Problem Statement
The Invitation model and InvitationsController are responsible for managing invitations between users in a team-based assignment system. The system allows a student to invite another student to their team by creating a new Invitation record, which is associated with the inviting and invited students and the assignment they are working on. The invited user can accept, decline, or cancel the invitation, which updates the corresponding Invitation record and may trigger actions such as adding or removing users from teams. The InvitationsController includes methods for creating, accepting, declining, and canceling invitations, as well as checking the status of the user and team before sending or accepting invitations. The system also sends email notifications to invited users when a new invitation is sent. Overall, the Invitation model and InvitationsController are crucial for managing team membership and collaboration in a team-based assignment system. Instructor’s note: There is already a project to merge this controller with the join_team_requests_controller. You should start with the code they have written.
Objectives
1. Write RESTful endpoints of create, show, delete to invitations and approving new invitations, listing pending invitations, creating new invitations, and notifying students about new team formation invite.
2. Develop and implement methods in the InvitationsController that enable the following functionality:Create invitations, Accept invitations, Decline invitations, Cancel invitations, and Check user and team status before sending or accepting invitations.
3. To implement a user-invitation system that allows invited users to accept, decline, or cancel invitations, which will update the corresponding Invitation record and trigger actions such as adding or removing users from teams.
4. Implement an email notification system in the user-invitation system, which sends email notifications to invited users when a new invitation is sent.
5. Return proper status codes and proper validation for RESTful endpoints.
6. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.
7. Write proper Rspec tests for all APIs, models, controllers.
Project Design and Implementation
Use Case Diagram
Functionality
In this project, we aim to add the following functions:
1. Enable users to create a new team invitation.
2. Enable users to Accept or Reject invitations.
3. Enable users to send email notifications to invited users.
4. Ensure that data is validated properly in all the above APIs.
5. Test cases for all the above.
Screen Shots
send an invite
accept an invite
reject invite
retract invite
we retracted invitation of angel and malka and added ofelia
Project Design
Controllers
We create a new controller at app/controllers/invitation_controller.rb with following methods:
A. REST Route methods
create:
This will create a new invitation record.
show:
This will be used to get the invitation for a particular assignment.
update:
This will be used to update the status of the current invitation. either accepted or rejected
destroy:
This will be used to delete the invitation that is already sent to another participant.
B. Helper methods
check_team_before_accept:
check if the inviter's team is still existing, and have an available slot to add the invitee.
check_team_before_invitation:
team has information about the team. check if the team is able to invite more participants.
check_participant_before_invitation:
check if the user is a participant in the assignment.
check_user_before_invitation:
check if the invited user is valid.
| Method | Endpoint | Request Body | Description | |
|---|---|---|---|---|
| 1 | show | GET /invitations/[assingment_id] | Get the invitations for the logged in user for the given assignment. | |
| 2 | create | POST/invitations/ | assingment_id: INT, from_id: INT, to_id: INT, reply_status: CHAR | Create a new invitation record with default reply_status: w, w stands for waiting. |
| 3 | update | PUT /invitations/<invite_id>/update | action=["accept"/"decline"] | Modify the status of the invitation to be accepted or declined. |
| 4 | destroy | GET /invitations/[assingment_id] | Delete the invitation |
end point description
show
Description: This route will be used to get the invitations for the logged in user for the given assignment. REST VERB: GET Path: /invitations/[assingment_id] Request: NA Response: Work in progress
create
Description: This route will create a new invitation record with default reply_status: w. w stands for waiting.
REST VERB: POST
Path: /invitations/
Request:
```
{
"assingment_id": INT,
"from_id": INT,
"to_id": INT,
"reply_status": w
}
```
Response: Work in progress
update
Description: This route will modify the status of the invitation to be accepted or declined
REST VERB: PUT
Path: /invitations/<invite_id>/update
Request:
```
{
"action": ["accept"/"decline"],
}
```
Response: Work in progress
destroy
Description: Delete the invitation REST VERB: DELETE Path: /invitations/<invite_id> Request: NA Response: Work in progress
Design Pattern
A design pattern refers to a commonly used solution to solve a recurring problem in software design. It provides a description or a blueprint for addressing a problem that can be used in various scenarios.
When refactoring methods and method names, the implementation utilized the Strategy pattern. The Strategy pattern is particularly beneficial when you need to offer several ways of handling a request without embedding information about those different methods into the object that manages the request.
Testing Plan
We utilized RSpec as the testing framework for our system. To test the RESTful APIs, we employed stubs and mocks. In order to enable stubbing, we generated new models and established associations as needed.
To run the tests:
1. git clone
2. cd reimplementation-back-end/
3. bundle install
4. bundle exec rspec spec/requests/api/v1/account_request_spec.rb
Tests
| Sr No | Test Description |
|---|---|
| 1 | Test to create a new invite with valid parameters |
| 2 | Test to create a new invite with invalid parameters |
| 3 | Test to create a duplicate invite |
| 4 | Test to create an invite with invalid user |
| 5 | Test to show the invitations for a particular assignment |
| 6 | Test to update the status of the invite with correct parameters |
| 7 | Test to update the status of the invite with incorrect parameters |
| 8 | Test to delete an invite with unauthorised access |
| 9 | Test to delete an invite with the authorised access |
| 10 | Test to show the invitations for a particular assignment |
| 11 | Test if the team is able to invite more participants before sending an invitation. |
| 12 | Test if the user is a participant in the assignment before sending an invite to that user. |
| 13 | Test if the invited user is valid before sending invite. |
Test Screenshot
Will be added soon
Swagger UI Screenshot
Will be added soon
References
Team Members
- Saigirishwar Rohit Geddam
- Keerthana Telaprolu
- Dhrumil Shah
Mentor
Ankur Mundra