[PATCH] A Timetable's Classes

[arafaysaleem]

Summary

As a student, I should be able to update classes of a timetable, so that I can adjust it according to my schedule.

Acceptance Criteria

GIVEN a student is editing classes in a timetable in the app
WHEN the app hits the /timetables/:id/classes endpoint with a valid PATCH request, containing:-
The path parameter:

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

And any of the following body parameters:

• The added key array contains class_erps of the newly added classes.
• The removed key array contains class_erps of the removed old classes.

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, //<-- should be equal to len(added)+len(removed)
    rows_changed: 1, //<-- should be equal to len(added)+len(removed)
    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

First Proposal

One option is to check conflicts with the added classes on the client and then simply send the class_erps to be removed and added. There is no need for conflict checking algorithm on the server side.

Second Proposal

Another viable option, which is actually much complex, is to check conflicts on the server side.

• A unchanged key array contains class_erps of the unchanged classes along with added and removed.

First of all the unchanged class_erps along with added ones are used to check conflicts among them. If no conflicts found then the removed ones are deleted and the new ones are added. All this happens in a transaction.

Testing Notes

Scenario 1: PATCH request is successful (Owner)

1. Update a timetables classes with a PATCH request to /timetables/:id/classes endpoint with student_erp == erp in student account token and ensure a 200 status code is returned.
2. A subsequent GET request to /timetables/:id endpoint should return a status code 200
3. And the timetable details with the updated information i.e. matching the newly sent updates.
4. Resubmit a PATCH request to /timetables/:id/classes endpoint to reverse the change and ensure status code 200 is returned.

Scenario 2: PATCH request is unsuccessful due to unknown timetable_id

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

Scenario 3: PATCH request is unsuccessful due to unknown class_erp

1. Update a timetable with a PATCH request to /timetables/:id/classes endpoint containing a non-existent class_erp in any of the key arrays.
2. Ensure a 512 status code is returned.
3. And the response headers' code parameter should contain "ForeignKeyViolationException"
4. And the response headers' message parameter should contain "class_erp"

Scenario 4: PATCH request is incorrect

1. Send a PATCH request to /timetables/:id/classes 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 5: PATCH request is forbidden (Unowned Student ERP)

1. Send a PATCH request to /timetables/:id/classes 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 6: PATCH request is unauthorized

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