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.
* 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>
Alex van Andel