This PR addresses definition errors currently residing within our
swagger doc.
~DISCLAIMER: There is still an error for our DELETE booking call, as
open API standard doesn't expect the DELETE call to contain a request
body, but we are requiring it in the way it currently works. Perhaps we
should move those to Query Parameters instead. Thoughts @zomars @emrysal
?~
It was taken care of by @leog and the docs are now updated as per the
endpoint
<img width="247" alt="image"
src="https://user-images.githubusercontent.com/52925846/217799706-21b7c21d-696b-4e20-a682-c8a949694b61.png">
<img width="629" alt="image"
src="https://user-images.githubusercontent.com/52925846/217799842-c903c23a-0b0d-4208-a3e9-01a682eeff97.png">
---------
Co-authored-by: Leo Giovanetti <hello@leog.me>
Co-authored-by: Omar López <zomars@me.com>
This allow us to manage our API keys directly from the API itself.
User can:
- Create own API keys
- Edit own API keys (only the note field for now)
- Delete own API keys
- Get own API keys
Admin can:
- CRUD for any user
- Get all API keys
## What does the PR do?
- Team billing via API
Just like the web project, we validate that team has stripe metadata
before converting requestedSlug to slug.
Co-authored-by: zomars <zomars@me.com>
This fix means a behaviour change to GET calls. Instead of a JSON
payload, instead a filter param has been added to the URL itself. GET
payloads are very unexpected in API designs, even though supported.
* Todo write tests (with postman?)
* Turn isAdmin logic into common middleware
```bash
curl "http://localhost:3002/v1/schedules?apiKey=...&userId=2"
```
```bash
curl "http://localhost:3002/v1/schedules?apiKey=..." \
-d '{"name":"Hello", "userId": 2}' \
-H 'Content-Type: application/json'
```
* List other user's availabilities
* /availabilityId methods for other users
* Add return statements
* Accept userId single value or array
* Add zod schema checks
* Filter for schedules only with an availability
* Adds safeParsing of JSON before safeParsing of zod
* Removed console log
* Adds safe JSON parsing before .safeParse
* Allow API call without necessarily passing userId
Allow `/availabilities` call by a regular user without having to pass their userId to make it work
Co-authored-by: Syed Ali Shahbaz <52925846+alishaz-polymath@users.noreply.github.com>