[PATCH] An Activity Attendee

[arafaysaleem]

Summary

As a student, I should be able to update involvement on an activity, so that I can update whether I'm attending or not.

Acceptance Criteria

GIVEN an student is updating his involvement on an activity in the app
WHEN the app hits the /activities/:id/attendees/:student_erp endpoint with a valid PATCH request, containing the path parameter:

• :id, the unique id of the entity being edited
• student_erp, the unique id of the entity being removed

AND any of the following body parameters:

• involvement_type enum('going','interested','will_try')

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 (Owner)

1. Update an activity attendee with a PATCH request to /activities/:id/attendees/:student_erp endpoint with student_erp == erp in student account token.
2. A subsequent GET request to /activities/:id/attendees/:student_erp endpoint should return a status code 200
3. And the activity attendee details with the updated information i.e. matching the initially sent body.
4. Resubmit a PATCH request to /activities/:id/attendees/:student_erp endpoint to reverse the change and ensure status code 200 is returned.

Scenario 2: PATCH request is successful (Admin)

1. Update an activity attendee with a PATCH request to /activities/:id/attendees/:student_erp endpoint using an admin account token.
2. A subsequent GET request to /activities/:id/attendees/:student_erp endpoint should return a status code 200
3. And the activity attendee details with the updated information i.e. matching the initially sent body.
4. Resubmit a PATCH request to /activities/:id/attendees/:student_erp endpoint to reverse the change and ensure status code 200 is returned.

Scenario 3: PATCH request is unsuccessful due to unknown activity_id

1. Make a PATCH request to /activities/:id/attendees/:student_erp endpoint containing a non-existent :id.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".
4. And the response headers' message parameter should contain "Activity attendee not found"

Scenario 4: PATCH request is unsuccessful due to unknown student erp

1. Make a PATCH request to /activities/:id/attendees/:student_erp endpoint containing a non-existent erp.
2. Ensure a 404 status code is returned.
3. And the response headers' code parameter should contain "NotFoundException".
4. And the response headers' message parameter should contain "Activity attendee not found"

Scenario 5: PATCH request is incorrect

1. Send a PATCH request to /activities/:id/attendees/:student_erp 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 6: PATCH request is forbidden

1. Send a PATCH request to /activities/:id/attendees/:student_erp endpoint with student_erp != erp in student account token.
2. Ensure the response returns a 403 forbidden status code.
3. And the response headers' code parameter should contain "ForbiddenException"

Scenario 7: PATCH request is unauthorized

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