Fixes - 2,3,4 security vulnerabilities reported in this message.
https://calendso.slack.com/archives/C03127U5S5Q/p1671922033089329
More Fixes
- Dont't allow a user to add a random attendee to a booking not owned by
him
- Don't allow a user to add a random cal user as an organizer of the
booking.
- Membership deletion should be as per the Privileges of
Owner,Admin,Member
Currently, anybody can create an event type for any team. With this PR
we only allow team ADMIN and OWNER to create event types for the team.
Co-authored-by: CarinaWolli <wollencarina@gmail.com>
Throw an error if a user of a team with ADMIN permission tries to change
permission to OWNER (Bug#3)
Co-authored-by: CarinaWolli <wollencarina@gmail.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>
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>
Udit Takkar
