Skip to content

Accepting store requests via REST

Alex requested to merge 798-store-request-endpoints into master

Part of &9

What does this MR do?

  • Moves the endpoint for accepting store requests to REST
  • Adds a check so that only existing requests can be accepted or rejected. Before, the API could have been used to add people to store even if they didn't send a request.
  • Adds unit tests for both endpoints (accepting and rejecting)

How confident are you it won't break things if deployed?

Works for me on localhost and I added unit tests. I don't think it will break anything.

How to test

Steps a reviewer can take to verify that this MR does what it says it does e.g.

  1. Checkout branch locally
  2. Login as foodsaver (e.g. user2)
  3. Send a request to a store, for example on the map
  4. Login as ambassador (userbot)
  5. Go to that store and accept the request
  6. The foodsaver should now be a team member

Checklist

  • added a test, or explain why one is not needed/possible...
  • no unrelated changes
  • asked someone for a code review
  • set a "for:" label to indicate who will be affected by this change
  • use "state:" labels to track this MR's state until it was beta tested
  • added an entry to CHANGELOG.md
  • add a short text that can be used in the release notes (for:Dev)
  • Once your MR has been merged, you are responsible to create a testing issue in Beta Testing Repo:
    • Consider writing a detailed description in German.
    • Describe in a few sentences, what should be tested from a user perspective.
    • Also mention different settings (e.g. different browsers, roles, ...). how this change can be tested.
    • Be aware, that also non technical people should understand.

Merge request reports