Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PATCH] Accept/Reject A Received Hangout Request #127

Closed
Tracked by #17
arafaysaleem opened this issue Oct 14, 2021 · 0 comments · Fixed by #129
Closed
Tracked by #17

[PATCH] Accept/Reject A Received Hangout Request #127

arafaysaleem opened this issue Oct 14, 2021 · 0 comments · Fixed by #129
Labels
Status: Completed Type: Feature user story A brief explanation of a functionality or an interaction with the system, from a user's perspective

Comments

@arafaysaleem
Copy link
Collaborator

Summary

As a student, I should be able to accept/reject hangout requests, so that I can meet/avoid new students.

Acceptance Criteria

GIVEN an student is accepting/rejecting a hangout request in the app
WHEN the app hits the /hangout-requests/:id endpoint with a valid PATCH request, containing the path parameter:

  • id, the unique id of the entity being edited

AND the following body parameters:

  • request_status, can be either 'accepted'/'rejected'
  • accepted_at datetime

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

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

Scenario 2: PATCH request is incorrect

  1. Send a PATCH request to /hangout-requests/: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 3: PATCH request is forbidden

  1. Send a PATCH request to /hangout-requests/:id endpoint with receiver_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 4: PATCH request is unauthorized

  1. Send a PATCH request to /hangout-requests/: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"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Completed Type: Feature user story A brief explanation of a functionality or an interaction with the system, from a user's perspective
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant