Description

This epic is a goal of the larger epic of REST API and contains functionality for authentication in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is a high impact goal as it provided the foundation for other API Epics.

Hypothesis

The API must provide person authentication, request validation and request verification. These things must be true by the end:

• Private API KEY/OAuth2 verification.
• Authorization token for each request.
• Person authentication procedures.
• Role based request access for each user.
• Documentation
• Tests

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• SIGNUP A Student #29
• LOGIN A Student #28
• CHANGE Password Of A Student #30
• REFRESH Auth Token #58
• FORGOT Password Of A Student #31

This API only focuses on auth related tasks for persons, requests and apps.

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation. No blockers so far

Description

This epic is a sub goal of the epic for Complete REST API and provides functionality surrounding management of classes. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our timetable module as without classes we can't create timetables. We want to create classes, along with their respective days and timeslots. We want to allow students query classes based on subjects or teachers. We should work on this immediately after setting up Classrooms API.

Hypothesis

We must have Authentication, Teachers, Classrooms, Timeslots and Subjects API setup prior to this. The following is true by the end of this API

• We can query/manage possible classes
• We can query/manage schedules of a class

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• #177
• #178
• #179 🔒
• #180 🔒
• #181 🔒
• Documentation For Each Endpoint
• Tests For Each Endpoint

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

3 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Students API and contains functionality for university assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage universities so that students can choose from them while creating their account. These student universities are also used to match similar students.

Hypothesis

The API must provide management of universities. This epic is considered complete when the following features are complete:

• Universities Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Universities
• GET A Single University
• POST A New University 🔒
• PATCH A University 🔒
• DELETE A University 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

1 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As an admin, I should be able to create interests, so that students can choose them while registering.

Acceptance Criteria

GIVEN an admin is creating an interest entry in the app
WHEN the app hits the /interests endpoint with a valid POST request, containing:

• hobby

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• interest id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "interest_id": "0",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: POST request is successful

1. Create a new interest entry with a POST request to /interests endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /interests/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a interest with the correct information i.e. matching the initially sent body.
4. Clean up the database by sending a DELETE request to /interests/:id endpoint and ensure a 200 status code is returned.

Scenario 2: POST request is incorrect

1. Send a POST request to /interests endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 3: POST request is forbidden

1. Send a POST request to /interests endpoint with a student account token.
2. Ensure a 403 forbidden status code is returned.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: POST request is unauthorized

1. Send a POST request to /interests endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a goal of the larger epic of Complete REST API and contains functionality for teacher reviews in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage teacher reviews so that students can add and read reviews and make decisions accordingly. We also want to moderate reviews before we allow them to be included in the calculation or directory of overall PR.

Hypothesis

The API must provide management of teacher reviews. This epic is considered complete when the following features are complete:

• Teacher Reviews Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication, Teachers, Subjects and Students API setup prior to this. In the end we need to have a collection of following endpoints:

• #171
• #172
• #173
• #174
• #175

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Complete REST API and contains functionality for timeslots selection in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage timeslot so that class schedules can be generated.

Hypothesis

The API must provide management of timeslots. This epic is considered complete when the following features are complete:

• Timeslots Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• #151 🔒
• #152 🔒
• #153 🔒
• #155 🔒
• #154 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Students API and provides functionality surrounding connections of students. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts all our unipal finder module as without this we can't create any connections for our project and we can't run matching algorithms. We want to be able to manage friend requests, friends and blocked users of a student. We want a two way relationship from the sending student to the receiving student and vice versa. We should work on this immediately after setting up Activities APIs.

Hypothesis

We must have Students API setup prior to this. The following is true by the end of this API

• We can manage friend requests for a student to multiple students
• We can mange friends of a student
• We can manage blocked users of a student

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• #115
• #113
• #116
• #114
• #119
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Complete REST API and contains functionality for campus classrooms management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage campus classrooms so the classes can be scheduled in one of them.

Hypothesis

The API must provide management of campus classrooms. This epic is considered complete when the following features are complete:

• Classrooms Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API and Campuses API setup prior to this. In the end we need to have a collection of following endpoints:

• #158 🔒
• #159 🔒
• #160 🔒
• #161 🔒
• #162 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Students API and contains functionality for student status assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage student statuses so that students can choose from them while operating their account. These student statuses are also used to match similar students.

Hypothesis

The API must provide management of student statuses. This epic is considered complete when the following features are complete:

• Student Statuses Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Student Statuses #53
• GET A Single Student Status #54
• POST A New Student Status 🔒 #52
• PATCH A Student Status 🔒 #56
• DELETE A Student Status 🔒 #55

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a student, I should be able to get all possible interests, so that I can choose from them in while signing up.

Acceptance Criteria

GIVEN an student is requesting all possible interests in the app
WHEN the app hits the /interests endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of interests

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        interest_id: 0,
        interest: "history"
    },
    {
        interest_id: 1,
        interest: "food"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is going to be accessible and work the same way for the admin as well.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting all possible interests in the app
WHEN the app hits the /interests endpoint with a valid GET request
THEN the app should receive a status 200
AND the body should be a list/an array
AND the first item of the array should be an object containing the following fields:

• interest_id
• interest

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting all possible interests in the app
WHEN the app hits the /interests endpoint with a valid GET request
THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting all possible interests in the app
WHEN the app hits the /interests endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Summary

As an admin, I should be able to create programs, so that students can choose them while registering.

Acceptance Criteria

GIVEN an admin is creating a program entry in the app
WHEN the app hits the /programs endpoint with a valid POST request, containing:

• program

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• program id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "program_id": "0",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: POST request is successful

1. Create a new program entry with a POST request to /programs endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /programs/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a program with the correct information i.e. matching the initially sent body.
4. Clean up the database by sending a DELETE request to /programs/:id endpoint and ensure a 200 status code is returned.

Scenario 2: POST request is incorrect

1. Send a POST request to /programs endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 3: POST request is forbidden

1. Send a POST request to /programs endpoint with a student account token.
2. Ensure a 403 forbidden status code is returned.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: POST request is unauthorized

1. Send a POST request to /programs endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As a student, I should be able to change my password, so that I can choose an updated one for security reasons.

Acceptance Criteria

GIVEN a student is logged in in the app
AND they change their password
WHEN the app hits the auth/change-password endpoint with a valid PATCH request, containing:

• erp
• old_password
• new_password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• rows matched
• rows changed

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    rows_matched: 1,
    rows_changed: 1,
    info: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: Change password request is successful

1. Send a PATCH request to /auth/change-password endpoint.
2. Ensure a 200 status code is returned.
3. And the response headers' message parameter says "Password changed successfully"
4. And the response body's rows_changed should be 1

Scenario 2: Change password request is unsuccessful due to unregisted erp

1. Send a PATCH request to /auth/change-password endpoint containing an unknown erp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter should contain an error pointing out incorrect credentials.
4. And the response headers' message parameter should contain string "ERP not registered".

Scenario 3: Change password request is unsuccessful due to invalid password

1. Send a PATCH request to /auth/change-password endpoint containing an incorrect password.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter should contain an error pointing out incorrect credentials.
4. And the response headers' message parameter should contain string "Incorrect password".

Scenario 4: Student password change request is incorrect

1. Send a PATCH request to /auth/change-password endpoint with an incorrect key name in the body.
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.

Summary

As an admin, I should be able to update the details of an interest, so that I can fix old or inconsistent entries.

Acceptance Criteria

GIVEN an admin is editing an interest in the app
WHEN the app hits the interests/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the entity of which the details are edited.

And any of the following body parameters:

• interest

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success
• rows matched
• rows changed

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {
    rows_matched: 1,
    rows_changed: 1,
    info: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: PATCH request is successful

1. Update a hobby with a PATCH request to /interests/:id endpoint
2. A subsequent GET request to /interests/:id endpoint should return a status code 200
3. And the interest details with the updated information i.e. matching the initially sent body.
4. Resubmit a PATCH request to interests/:id endpoint to reverse the change and ensure status code 200 is returned.

Scenario 2: PATCH request is unsuccessful

1. Update a interest with a PATCH request to /interests/:id endpoint containing a non-existent interest_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: PATCH request is incorrect

1. Send a PATCH request to /interests/:id endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 4: PATCH request is forbidden

1. Send a PATCH request to /interests/:id endpoint using a student account token.
2. Ensure the response returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 5: PATCH request is unauthorized

1. Send a PATCH request to /interests endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As an admin, I should be able to update the details of a hobby, so that I can fix old or inconsistent hobby entries.

Acceptance Criteria

GIVEN an admin is editing a hobby in the app
WHEN the app hits the hobbies/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the hobby of which the details are edited.

And any of the following body parameters:

• hobby

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success
• rows matched
• rows changed

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {
    rows_matched: 1,
    rows_changed: 1,
    info: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: PATCH request is successful

1. Update a hobby with a PATCH request to /hobbies/:id endpoint
2. A subsequent GET request to /hobbies/:id endpoint should return a status code 200
3. And the hobby details with the updated information i.e. matching the initially sent body.
4. Resubmit a PATCH request to hobbies/:id endpoint to reverse the change and ensure status code 200 is returned.

Scenario 2: PATCH request is unsuccessful

1. Update a hobby with a PATCH request to /hobbies/:id endpoint containing a non-existent hobby_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: PATCH request is incorrect

1. Send a PATCH request to /hobbies/:id endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 4: PATCH request is forbidden

1. Send a PATCH request to /hobbies/:id endpoint using a student account token.
2. Ensure the response returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 5: PATCH request is unauthorized

1. Send a PATCH request to /hobbies endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As a student, I should be able to forgot my password, so that I can reset it and gain access to my account.

Acceptance Criteria

Scenario 1: Student requests a password reset code

GIVEN a student is choosing forgot password in the app
WHEN the app hits the auth/forgot/send-otp endpoint with a valid POST request, containing:

• erp

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• OTP sent message

Sample Request/Sample Response

headers: {
    error: 0,
    message: "OTP generated and sent via email"
}
body: {}

Scenario 2: Student requests otp verification

GIVEN a student is verifying otp in the app
WHEN the app hits the auth/forgot/verify-otp endpoint with a valid POST request, containing:

• 4 digit OTP

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• OTP verified message

Sample Request/Sample Response

headers: {
    error: 0,
    message: "OTP verified succesfully"
}
body: {}

Scenario 3: Student requests password reset

GIVEN a student is resetting password in the app
WHEN the app hits the auth/forgot/reset-password endpoint with a valid request, containing:

• erp
• new_password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• password reset successful

Sample Request/Sample Response

headers: {
    error: 0,
    message: "Password reset successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: Student otp code request is successful

1. Send a POST request to /auth/forgot/send-otp endpoint.
2. Ensure a 200 status code is returned.
3. And the response headers' message parameter says "OTP generated and sent via email"

Scenario 2: Student otp code request is unsuccessful due to unknown erp

1. Send a POST request to /auth/forgot/send-otp endpoint with an unregistered erp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter should contain an error pointing out incorrect credentials.
4. And the response headers' message parameter should contain string "ERP not registered".

Scenario 3: Student otp code request is incorrect

1. Send a PATCH request to /auth/forgot/send-otp endpoint with an incorrect key name in the body.
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.
4. 4. And the response headers' data parameter should contain name of the incorrectly specified key.

Scenario 4: Student otp code verification is successful

1. Send a POST request to /auth/forgot/verify-otp endpoint.
2. Ensure a 200 status code is returned.
3. And the response headers' message parameter says "OTP verified succesfully"

Scenario 5: Student otp code verification is unsuccessful due to invalid otp

1. Send a POST request to /auth/forgot/verify-otp endpoint with an invalid otp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter says "OTPVerificationException"
4. And the response headers' message parameter says "OTP verification failed"

Scenario 6: Student otp code verification is unsuccessful due to unknown erp

1. Send a POST request to /auth/forgot/verify-otp endpoint with an unknown erp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter says "OTPVerificationException"
4. And the response headers' message parameter says "No OTP found for this ERP"

Scenario 7: Student otp code verification is unsuccessful due to expired otp

1. Send a POST request to /auth/forgot/verify-otp endpoint with an expired otp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter says "OTPExpiredException"

Scenario 8: Student otp code verification is incorrect

1. Send a POST request to /auth/forgot/verify-otp endpoint with an incorrect key name in the body.
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.
4. And the response headers' data parameter should contain name of the incorrectly specified key.

Scenario 7: Student password reset request is successful

1. Send a PATCH request to /auth/forgot/reset-password endpoint.
2. Ensure a 200 status code is returned.
3. And the response headers' message parameter says "Password reset successfully"
4. And the response body's rows_changed should be 1

Scenario 8: Student password reset request is unsuccessful due to unknown erp

1. Send a PATCH request to /auth/forgot/reset-password endpoint with an unregistered erp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter says "InvalidCredentialsException"
4. And the response headers' message parameter says "ERP not registered"

Scenario 9: Student password reset request is incorrect

1. Send a POST request to /auth/forgot/reset-password endpoint with an incorrect key name in the body.
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.
4. And the response headers' data parameter should contain name of the incorrectly specified key.

Summary

As a student, I should be able to get details of a campus, so that I can understand what information it represents.

Acceptance Criteria

GIVEN an student is requesting details of a campus in the app
WHEN the app hits the /campuses/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the entity for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• campus details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    campus_id: 2,
    campus: "MAIN"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the admin in the same way.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting details of a campus in the app
WHEN the app hits the /campuses/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting details of a campus in the app
WHEN the app hits the /campuses/:id endpoint with a valid GET request, containing the path parameter:

• :id, a non-existent id

THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting details of a campus in the app
WHEN the app hits the /campuses/:id endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a goal of the larger epic of Posts API and contains functionality for managing standard reactions in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage reaction types so that students can choose from them while reacting to posts.

Hypothesis

The API must provide management of reaction types. This epic is considered complete when the following features are complete:

• Reaction Types Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• #131
• #132
• #130 🔒
• #133 🔒
• #134 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a large component of the overall project and is used to communicate between our server and our apps. This epic needs to prepare a working, fully functional REST API with multiple endpoints for use cases.

Initiative / goal

It is high impact since it used to communicate between our server and our apps so without this the project can not work.

Hypothesis

A documented API is received in the end containing all functionalities for the project. These are the endpoint collections it must have:

• #9
• #14
• #12
• #13
• #5
• #8
• #7
• #11
• #3
• #4
• #15
• #16
• #17
• #19
• #18
• #21
• #22
• #23
• #20
• #24
• #25
• #26
• #27
• Health Check

Acceptance criteria and must have scope

We need documentation, tested API endpoint URLs, Postman collection for each endpoints and a backup of the database schema and data.

Stakeholders

@diablo-shotgun @sfurqan2 are members of the engineering team who will verify the completion.

Timeline

3 months is the approximate timeline, a working deployable server is needed for the API as well as the DB instance. Currently, there are no identified blockers.

Summary

As a student, I should be able to get details of a hobby, so that I can understand what information it represents.

Acceptance Criteria

GIVEN an student is requesting details of a hobby in the app
WHEN the app hits the hobbies/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the entity for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• hobby details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    hobby_id: 2,
    hobby: "painting"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the admin in the same way.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting details of a hobby in the app
WHEN the app hits the hobbies/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting details of a hobby in the app
WHEN the app hits the hobbies/:id endpoint with a valid GET request, containing the path parameter:

• :id, a non-existent id

THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting all possible hobbies in the app
WHEN the app hits the /hobbies endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a sub goal of the epic for Students API and provides functionality surrounding connections of students. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts all our connections module as without this we have limited functionality to interact with other students in our project. We want to be able to manage hangout requests of a student. We should work on this immediately after setting up Friends API.

Hypothesis

We must have Students API setup prior to this. The following is true by the end of this API

• We can create hangout requests for a student to multiple students
• We can delete hangout requests for a student
• We can update hangout requests for a student

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• #125
• #126
• #127
• #128
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Complete REST API and provides functionality surrounding saving timetables. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our timetable management module as without it we can't match students with overlaps. We want to allow students create multiple timetables, set one of them as active. We want to allow students to add classes in their timetables. We want to show all the timetables of a student. We want to show all the classes of a timetable. We should work on this immediately after setting up Classes API.

Hypothesis

We must have Students and Classes API setup prior to this. The following is true by the end of this API

• We can query/manage possible timetables
• We can generate possible timetables from given classes
• Documentation For Each Endpoint
• Tests For Each Endpoint

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• #212
• #213
• #218
• #214
• #215
• #216
• #217

Stakeholders

None

Timeline

3 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a student, I should be able to get details of a interest, so that I can understand what information it represents.

Acceptance Criteria

GIVEN an student is requesting details of an interest in the app
WHEN the app hits the interests/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the entity for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• interest details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    interest_id: 2,
    interest: "sports"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the admin in the same way.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting details of an interest in the app
WHEN the app hits the /interests/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting details of an interest in the app
WHEN the app hits the /interests/:id endpoint with a valid GET request, containing the path parameter:

• :id, a non-existent id

THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting details of an interest in the app
WHEN the app hits the /interests/:id endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Summary

As a student, I should be able to signup, so that I can access features of this app.

Acceptance Criteria

GIVEN an student is signing up in the app
WHEN the app hits the /auth/register endpoint with a valid POST request, containing:

• erp
• first_name
• last_name
• gender
• contact
• email
• birthday
• password
• profile_picture_url
• graduation_year
• uni_email
• hobby1
• hobby2
• hobby3
• interest1
• interest2
• interest3
• program_id
• campus_id
• favourite_campus_hangout_spot
• favourite_campus_activity
• current_user_status
• is_active
• role

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• student profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
    token: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

• The response should omit the password from the profile.
• The response should contain joined values for the foreign key fields.

Testing Notes

Scenario: Register request is successful

1. Create a new student with a POST request to /auth/register endpoint and ensure a 201 status code is returned.
2. Ensure the response contains a student profile with the correct information i.e. matching the initially sent body.
3. And also contains a token parameter.
4. Clean up the database by sending a DELETE request to /students/:erp endpoint and ensure a 200 status code is returned.

Scenario: Register request is unsuccessful due to duplicate student

1. Create a new student with a POST request to /auth/register endpoint containing a pre-existing student erp.
2. Ensure a 409 status code is returned.
3. And the response headers' code parameter should contain an error pointing out duplicate key exception.

Scenario: Register request is incorrect

1. Send a POST request to /auth/register endpoint with an incorrect key name in the body.
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.

Description

This epic is a goal of the larger epic of Students API and contains functionality for interests assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage interests so that students can choose from them while creating accounts. These interests are also used to match similar students.

Hypothesis

The API must provide management of interests. This epic is considered complete when the following features are complete:

• Interests Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Interests #43
• GET A Single Interest #42
• POST A New Interest 🔒 #33
• PATCH A Interest 🔒 #40
• DELETE A Interest 🔒 #41

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a student, I should be able to get all possible programs, so that I can choose from them in while signing up.

Acceptance Criteria

GIVEN an student is requesting all possible programs in the app
WHEN the app hits the /programs endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of programs

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        program_id: 0,
        program: "BSCS"
    },
    {
        program_id: 1,
        program: "MBA"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is going to be accessible and work the same way for the admin as well.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting all possible programs in the app
WHEN the app hits the /programs endpoint with a valid GET request
THEN the app should receive a status 200
AND the body should be an array
AND the first item of the array should be an object containing the following fields:

• program_id
• program

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting all possible programs in the app
WHEN the app hits the /programs endpoint with a valid GET request
THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting all possible programs in the app
WHEN the app hits the /programs endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a sub goal of the epic for Complete REST API and provides functionality surrounding students. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts all activity management module as without it students can't organize and activities or invite other students. We want to be able to manage create. We want to allow students to attend activities. We want to be able to post activities on activities feed. We should work on this soon after setting up Students API.

Hypothesis

We must have Authentication, Activity Types, Activity Statuses, Campus Spots and Students API setup prior to this. The following is true by the end of this API

• We can query/manage activities
• We can choose an activity type for an activity. #13
• We can choose an activity status for an activity. #12
• We can choose a campus spot as a fixed spot for an activity. #11
• We can query/manage possible attendees of an activity

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• #91
• #96
• #92
• #94
• #97
• #95
• #99
• #93
• #98
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

3 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Universities API and contains functionality for programs management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage programs so that students can choose from them while creating their account and classes can be setup. These programs are also used to match similar students.

Hypothesis

The API must provide management of programs. This epic is considered complete when the following features are complete:

• Programs Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API and Universities API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Programs #48
• GET A Single Program #49
• POST A New Program 🔒 #35
• PATCH A Program 🔒 #51
• DELETE A Program 🔒 #50

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As an admin, I should be able to create hobbies, so that students can choose them while registering.

Acceptance Criteria

GIVEN an admin is creating a hobby entry in the app
WHEN the app hits the /hobbies endpoint with a valid POST request, containing:

• hobby

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• hobby id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "hobby_id": "0",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: POST request is successful

1. Create a new hobby entry with a POST request to /hobbies endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /hobbies/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a hobby with the correct information i.e. matching the initially sent body.
4. Clean up the database by sending a DELETE request to /hobbies/:id endpoint and ensure a 200 status code is returned.

Scenario 2: POST request is incorrect

1. Send a POST request to /hobbies endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 3: POST request is forbidden

1. Send a POST request to /hobbies endpoint with a student account token.
2. Ensure a 403 forbidden status code is returned.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: POST request is unauthorized

1. Send a POST request to /hobbies endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a goal of the larger epic of Students API and contains functionality for hobbies assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage hobbies so that students can choose from them while creating accounts. These hobbies are also used to match similar students.

Hypothesis

The API must provide management of hobbies. This epic is considered complete when the following features are complete:

• Hobbies Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Hobbies #39
• GET A Single Hobby #38
• POST A New Hobby 🔒 #32
• PATCH A Hobby 🔒 #36
• DELETE A Hobby 🔒 #37

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Students API and provides functionality surrounding friends of students. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts all our unipal finder and memories feed modules as without this we can't show relevant memories on the feed and we can't run matching algorithms. We want to be able to manage friends of a student. We want a two way relationship from the initiating student to the accepting student and vice versa. We should work on this immediately after setting up Friend Requests API.

Hypothesis

We must have Friend Requests and Students API setup prior to this. The following is true by the end of this API

• We can create friendships for a student
• We can delete friendships for a student
• We can update friendships for a student

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• GET All Friends (Temporary - For testing only)
• POST A New Friendship For A Student
• PATCH A Friendship For A Student
• DELETE A Friendship For A Student
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a student, I should be able to get all possible campuses, so that I can choose from them in while signing up.

Acceptance Criteria

GIVEN an student is requesting all possible campuses in the app
WHEN the app hits the /campuses endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of campuses

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        campus_id: 0,
        campus: "MAIN"
    },
    {
        campus_id: 1,
        campus: "CITY"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is going to be accessible and work the same way for the admin as well.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting all possible campuses in the app
WHEN the app hits the /campuses endpoint with a valid GET request
THEN the app should receive a status 200
AND the body should be an array
AND the first item of the array should be an object containing the following fields:

• campus_id
• campus

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting all possible campuses in the app
WHEN the app hits the /campuses endpoint with a valid GET request
THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting all possible campuses in the app
WHEN the app hits the /campuses endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a goal of the larger epic of Universities API and contains functionality for campus spots management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage campus spots so that students can choose from them while creating activities and while sending hangout requests. These campus spots are also used to match similar students.

Hypothesis

The API must provide management of campus spots. This epic is considered complete when the following features are complete:

• Campus Spots Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API and Campuses API setup prior to this. In the end we need to have a collection of following endpoints:

• #83
• #84
• #82 🔒
• #85 🔒
• #86 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Universities API and contains functionality for campus management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage campuses so that students can choose from them while creating their account and classrooms can be setup. These campuses are also used to match similar students.

Hypothesis

The API must provide management of campuses. This epic is considered complete when the following features are complete:

• Campuses Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API and Universities API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Campuses #44
• GET A Single Campus #45
• POST A New Campus 🔒 #34
• PATCH A Campus 🔒 #47
• DELETE A Campus 🔒 #46

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Activities API and contains functionality for activity types assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage activity types so that students can choose from them while managing activities. These activity types are also used to match similar activities for students.

Hypothesis

The API must provide management of activity types. This epic is considered complete when the following features are complete:

• Activity Types Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• #78
• #79
• #77 🔒
• #80 🔒
• #81 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a student, I should be able to get all possible hobbies, so that I can choose from them in while signing up.

Acceptance Criteria

GIVEN an student is requesting all possible hobbies in the app
WHEN the app hits the /hobbies endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of hobbies

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        hobby_id: 0,
        hobby: "painting"
    },
    {
        hobby_id: 1,
        hobby: "playing an instrument"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is going to be accessible and work the same way for the admin as well.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting all possible hobbies in the app
WHEN the app hits the /hobbies endpoint with a valid GET request
THEN the app should receive a status 200
AND the body should be an array
AND the first item of the array should be an object containing the following fields:

• hobby_id
• hobby

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting all possible hobbies in the app
WHEN the app hits the /hobbies endpoint with a valid GET request
THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting all possible hobbies in the app
WHEN the app hits the /hobbies endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a sub goal of the epic for Complete REST API and provides functionality surrounding students. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts all our modules as without students we can't create timetables, activities or any connections for our project and we can't proceed. We want to be able to manage activities. We want to build and search connections. We want to be able to post memories. We want to allow generating and sharing timetables. We should work on this immediately after setting up Preferences APIs.

Hypothesis

We must have Authentication, Hobbies, Interests, Universities, Campuses, Programs and User Statuses API setup prior to this. The following is true by the end of this API

• We can query/manage possible profile of a student
• We can query/manage possible organized activities of a student #14
• We can query/manage possible saved activities of a student #14
• We can query/manage possible attending activities of a student #14

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• GET All Students #67
• #105
• #106
• #107
• GET A Single Student #68
• PATCH A Student #69
• DELETE A Student #70
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

5 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Complete REST API and provides functionality surrounding sharing timetables. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our timetable management module as without it we can't share timetables with other students and find out overlaps. We want to allow students create multiple timetable sharing rooms, each with a fixed timetable to be matched against. We want to allow students to add other students in that room. We want to allow members of a room to share their own timetables. We want to show all the members of a room. We should work on this immediately after setting up Timetables API.

Hypothesis

We must have Students and Timetables API setup prior to this. The following is true by the end of this API

• We can query/manage timetable share rooms (TSR)
• We can query/manage possible members of a TSR

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• GET All Timetable Share Rooms (Temp - Testing Only)
• GET A Single Timetable Share Room
• GET A Single Timetable Share Room's Members
• POST A New Timetable Share Room
• POST A New Timetable Share Room Member
• PATCH A Timetable Share Room
• PATCH A Timetable Share Room Member
• DELETE A Timetable Share Room
• DELETE A Timetable Share Room Member
• Documentation For Each Endpoint
• Tests For Each Endpoint

Note: Should load all classes for each TSR timetable

Stakeholders

None

Timeline

3 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a student, I should be able to get details of a program, so that I can understand what information it represents.

Acceptance Criteria

GIVEN an student is requesting details of a program in the app
WHEN the app hits the /programs/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the entity for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• program details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    program_id: 2,
    program: "BSACF"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the admin in the same way.

Testing Notes

Scenario 1: GET request is successful

GIVEN a student is requesting details of a program in the app
WHEN the app hits the /programs/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Scenario 2: GET request is unsuccessful

GIVEN a student is requesting details of a program in the app
WHEN the app hits the /programs/:id endpoint with a valid GET request, containing the path parameter:

• :id, a non-existent id

THEN the app should receive a status 404
AND the response headers' code parameter should contain "NotFoundException"

Scenario 3: GET request is forbidden

GIVEN a student is requesting details of a program in the app
WHEN the app hits the /programs/:id endpoint with a valid GET request
AND the request contains no authorization token
THEN the app should receive a status 401
AND the response headers' code parameter should contain "TokenMissingException"

Summary

As an admin, I should be able to update the details of an campus, so that I can fix old or inconsistent entries.

Acceptance Criteria

GIVEN an admin is editing a campus in the app
WHEN the app hits the campuses/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the entity of which the details are edited.

And any of the following body parameters:

• campus

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success
• rows matched
• rows changed

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {
    rows_matched: 1,
    rows_changed: 1,
    info: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: PATCH request is successful

1. Update a campus with a PATCH request to /campuses/:id endpoint
2. A subsequent GET request to /campuses/:id endpoint should return a status code 200
3. And the campus details with the updated information i.e. matching the initially sent body.
4. Resubmit a PATCH request to /campuses/:id endpoint to reverse the change and ensure status code 200 is returned.

Scenario 2: PATCH request is unsuccessful

1. Update a campus with a PATCH request to /campuses/:id endpoint containing a non-existent campus_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: PATCH request is incorrect

1. Send a PATCH request to /campuses/:id endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 4: PATCH request is forbidden

1. Send a PATCH request to /campuses/:id endpoint using a student account token.
2. Ensure the response returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 5: PATCH request is unauthorized

1. Send a PATCH request to /campuses/:id endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As an admin, I should be able to delete campuses, so that I can remove old or inconsistent entries.

Acceptance Criteria

GIVEN an admin is deleting a campus in the app
WHEN the app hits the /campuses/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the entity being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: DELETE request is successful:

1. Create a new campus with a POST request to /campuses endpoint and ensure status code 200 is returned.
2. With the id returned from the POST, make a DELETE request to /campuses/:id endpoint and ensure status code 200 is returned.
3. A subsequent GET request to /campuses/:id endpoint should return a status code 404.
4. And the response headers' code parameter should contain "NotFoundException".

Scenario 2: DELETE request is unsuccessful

1. Make a DELETE request to /campuses/:id endpoint containing a non-existent campus_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: DELETE request is forbidden:

1. Make a DELETE request to /campuses/:id endpoint using a student account token.
2. Ensure the endpoint returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: DELETE request is unauthorized

1. Send a DELETE request to /campuses/:id endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As an admin, I should be able to create campuses, so that students can choose them while registering.

Acceptance Criteria

GIVEN an admin is creating an interest entry in the app
WHEN the app hits the /campuses endpoint with a valid POST request, containing:

• campus

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• campus id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "campus_id": "0",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: POST request is successful

1. Create a new campus entry with a POST request to /campuses endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /campuses/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a campus with the correct information i.e. matching the initially sent body.
4. Clean up the database by sending a DELETE request to /campuses/:id endpoint and ensure a 200 status code is returned.

Scenario 2: POST request is incorrect

1. Send a POST request to /campuses endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain "InvalidPropertiesException".
4. And the response headers' data parameter should contain the name of the invalid parameter.

Scenario 3: POST request is forbidden

1. Send a POST request to /campuses endpoint with a student account token.
2. Ensure a 403 forbidden status code is returned.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: POST request is unauthorized

1. Send a POST request to /campuses endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a goal of the larger epic of Universities API and contains functionality for campus spots management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage campus spots so that students can choose from them while creating activities and while sending hangout requests. These campus spots are also used to match similar students.

Hypothesis

The API must provide management of campus spots. This epic is considered complete when the following features are complete:

• Campus Spots Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API and Campuses API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Campus Spots
• GET A Single Campus Spot
• POST A New Campus Spot 🔒
• PATCH A Campus Spot 🔒
• DELETE A Campus Spot 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As an admin, I should be able to delete interests, so that I can remove old or inconsistent entries.

Acceptance Criteria

GIVEN an admin is deleting an interest in the app
WHEN the app hits the interests/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the entity being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: DELETE request is successful:

1. Create a new interest with a POST request to /interests endpoint and ensure status code 200 is returned.
2. With the id returned from the POST, make a DELETE request to /interests/:id endpoint and ensure status code 200 is returned.
3. A subsequent GET request to /interests/:id endpoint should return a status code 404.
4. And the response headers' code parameter should contain "NotFoundException".

Scenario 2: DELETE request is unsuccessful

1. Make a DELETE request to /interests/:id endpoint containing a non-existent interest_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: DELETE request is forbidden:

1. Make a DELETE request to /interests/:id endpoint using a student account token.
2. Ensure the endpoint returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: DELETE request is unauthorized

1. Send a DELETE request to /interests endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Description

This epic is a goal of the larger epic of Complete REST API and contains functionality for subject assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage subjects so that classes can be created.

Hypothesis

The API must provide management of subjects. This epic is considered complete when the following features are complete:

• Subjects Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• #146 🔒
• #147 🔒
• #150 🔒
• #148 🔒
• #149 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Complete REST API and provides functionality surrounding posting memories. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our memories feed module as without posts the feed will show no data. We want to allow students to make new posts, optionally with some images or videos. We want to allow students to react to posts. We want to show all the reactions and uploads of a post. We should work on this immediately after setting up Hangout Requests API.

Hypothesis

We must have Students and Reaction Types API setup prior to this. The following is true by the end of this API

• We can query/manage possible posts and it's uploads
• We can query/manage possible reactions of a post

Acceptance criteria and must have scope

In the end we need to have a collection of following endpoints:

• #136
• #137
• #140
• #139
• #138
• #144
• #141
• #143
• #142
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

3 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Complete REST API and contains functionality for teacher assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage teachers so that classes can be created. We also want to query teachers so they can be displayed
along with their ratings, while generating timetables. We also want to query a teacher so it's overall rating can be updated each time a new review is added.

Hypothesis

The API must provide management of teachers. This epic is considered complete when the following features are complete:

• Teachers Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Teachers 🔒
• GET A Single Teacher 🔒
• POST A New Teacher 🔒
• PATCH A Teacher 🔒
• DELETE A Teacher 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a goal of the larger epic of Activities API and contains functionality for activity status assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to manage activity statuses so that students can choose from them while managing activities. These activity statuses are also used to match similar activities for students.

Hypothesis

The API must provide management of activity statuses. This epic is considered complete when the following features are complete:

• Activity Statuses Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• #73
• #74
• #72 🔒
• #75 🔒
• #76 🔒

Note: 🔒 symbol indicates the route is protected and accessible to admin only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As an admin, I should be able to delete hobbies, so that I can remove old or inconsistent entries.

Acceptance Criteria

GIVEN an admin is deleting a hobby in the app
WHEN the app hits the hobbies/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the entity being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: DELETE request is successful:

1. Create a new hobby with a POST request to /hobbies endpoint and ensure status code 200 is returned.
2. With the id returned from the POST, make a DELETE request to /hobbies/:id endpoint and ensure status code 200 is returned.
3. A subsequent GET request to /hobbies/:id endpoint should return a status code 404.
4. And the response headers' code parameter should contain "NotFoundException".

Scenario 2: DELETE request is unsuccessful

1. Make a DELETE request to /hobbies/:id endpoint containing a non-existent hobby_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: DELETE request is forbidden:

1. Make a DELETE request to /hobbies/:id endpoint using a student account token.
2. Ensure the endpoint returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: DELETE request is unauthorized

1. Send a DELETE request to /hobbies endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As an admin, I should be able to delete programs, so that I can remove old or inconsistent entries.

Acceptance Criteria

GIVEN an admin is deleting a program in the app
WHEN the app hits the programs/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the entity being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: DELETE request is successful:

1. Create a new program with a POST request to /programs endpoint and ensure status code 200 is returned.
2. With the id returned from the POST, make a DELETE request to /programs/:id endpoint and ensure status code 200 is returned.
3. A subsequent GET request to /programs/:id endpoint should return a status code 404.
4. And the response headers' code parameter should contain "NotFoundException".

Scenario 2: DELETE request is unsuccessful

1. Make a DELETE request to /programs/:id endpoint containing a non-existent program_id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".

Scenario 3: DELETE request is forbidden:

1. Make a DELETE request to /programs/:id endpoint using a student account token.
2. Ensure the endpoint returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 4: DELETE request is unauthorized

1. Send a DELETE request to /programs/:id endpoint without an authorization token
2. Ensure a 401 unauthorized status code is returned.
3. And the response headers' code parameter should contain "TokenMissingException"

Summary

As a student, I should be able to login, so that I can access the features of this app

Acceptance Criteria

GIVEN a student is logging in in the app
WHEN the app hits the auth/login endpoint with a valid POST request, containing:

• student_erp/email
• password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• student profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
    token: '...'
}

Resources

• Development URL: [Here goes a URL to the feature on development API];
• Production URL: [Here goes a URL to the feature on production API];

Dev Notes

[Some complementary notes if necessary:]

• The response should omit the password from the profile
• The response should contain joined values for the foreign key fields

Testing Notes

Scenario: Login request is successful

1. Get a student profile with a POST request to /auth/login endpoint.
2. Ensure a 200 status code is returned.
3. Ensure the response contains a student profile with the correct information i.e. matching the initially sent body.

Scenario: Login request is unsuccessful

1. Request a student profile with a POST request to /auth/login endpoint containing an unknown erp.
2. Ensure a 401 status code is returned.
3. And the response headers' code parameter should contain an error pointing out incorrect credentials.

Scenario: Login request is incorrect

1. Send a POST request to /auth/login endpoint with an incorrect key name in the body.
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.