Follows-up on earlier discussions about the relationships of
/availabilities and /schedules.
`GET /schedules/:id` returns a schedule with associated availabilities
in the `availabilities` property. It gives more context and less
consumer work to perform GET actions using this endpoint. Other
endpoints of this collection do make sense.
Proposing also to rename the /availabilities collection to
/availability; given after this it always involves one and only one
/availability record in CRUD.
Implemented `DELETE /booking/:uid` as well as `DELETE
/booking/:uid/cancel` based on abstracted cancellation logic from
webapp.
PR dependant on https://github.com/calcom/cal.com/pull/5105
Co-authored-by: Alex van Andel <me@alexvanandel.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'
```
authMiddleware should not use defaultResponder directly as it will catch thrown error and we need those errors to prevent running the rest of the code.
* 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>
zomars