|
|
| Line 1: |
Line 1: |
| ==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 ===
| |
| [[File:Usecasediagram1.png|700px]]
| |
|
| |
| ===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 ====
| |
| [[File:Dshah6_send_invite.png|900px]]
| |
| [[File:Dshah6_send_invite_2.png|900px]]
| |
| [[File:Dshah6_send_invite_3.png|900px]]
| |
|
| |
| ==== accept an invite ====
| |
| [[File:Dshah6_accept_1.png|900px]]
| |
| [[File:Dshah6_accept_2.png|900px]]
| |
| [[File:Dshah6_accept_3.png|900px]]
| |
|
| |
| ==== reject invite ====
| |
| [[File:Dshah6_decline_1.png|900px]]
| |
| [[File:Dshah6_decline_2.png|900px]]
| |
|
| |
| ==== retract invite ====
| |
| [[File:Dshah6_retract_1.png|900px]]
| |
|
| |
| ==== we retracted invitation of angel and malka and added ofelia ====
| |
|
| |
| [[File:Dshah6_retract_2.png|900px]]
| |
|
| |
| = 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.
| |
|
| |
| {| class="wikitable" style="margin-left:40px"
| |
| |-
| |
| ! 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==
| |
|
| |
| <b>show</b>
| |
| <pre>
| |
|
| |
| 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
| |
| </pre>
| |
|
| |
| <b>create</b>
| |
| <pre>
| |
|
| |
|
| |
| 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
| |
| </pre>
| |
|
| |
| <b>update</b>
| |
| <pre>
| |
|
| |
| 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
| |
| </pre>
| |
|
| |
| <b>destroy</b>
| |
| <pre>
| |
|
| |
| Description: Delete the invitation
| |
| REST VERB: DELETE
| |
| Path: /invitations/<invite_id>
| |
| Request: NA
| |
| Response: Work in progress
| |
| </pre>
| |
|
| |
| ==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====
| |
|
| |
| {| class="wikitable" style="margin-left:30px"
| |
| |-
| |
| ! 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=
| |
|
| |
| * [https://github.com/rohitgeddam/reimplementation-back-end/ Github Link]
| |
|
| |
| * [https://www.rubyguides.com/2015/12/ruby-refactoring/ Introduction to Refractoring in Ruby]
| |
|
| |
| * [http://rspec.info/documentation/3.8/rspec-core/ Rspec Documentation]
| |
|
| |
| =Team Members=
| |
|
| |
| * Saigirishwar Rohit Geddam
| |
| * Keerthana Telaprolu
| |
| * Dhrumil Shah
| |
|
| |
| =Mentor=
| |
| Ankur Mundra
| |